What's it all about, Alfie?

In a very interesting article from the Financial Times, it seems that Google's recent brush with the Chinese hackers that compromised their systems has left them looking for the real root causes of the incident. To that end, they have decided that it's Windows that is the security threat, not the people:

New hires are now given the option of using Apple’s Mac computers or PCs running the Linux operating system. “Linux is open source and we feel good about it,” said one employee. “Microsoft we don’t feel so good about.”

Indeed, the source points to the security (or lack thereof) of Windows as the primary reason:

In addition to being a semi-formal policy, employees themselves have grown more concerned about security since the China attacks. “Particularly since the China scare, a lot of people here are using Macs for security,” said one employee.

Interesting. It says a lot about Google that they don't go the "lock down" approach to the machines - they realize that people need to be able to do things on their machines in order to get work done. So rather than try to make Windows secure, it's easier to just ban it.

Amazing.

This is really frustrating. This morning, out of nowhere, one of my Tomcat webservers was taking far longer to return data than normal. By 'far longer', I mean 5 to 10 seconds when yesterday it was sub-second. Really. It's a factor of 10x to 30x in response time. Horrible.

So I'm trying to figure this out. It's not a resource issue - got plenty of memory and CPU... it's not the code - it's running fine in London and NYC... it's not a simple data error - restarts and even different JVM GC parameters makes no difference at all.

It could be hardware. It could be networking. I seem to be getting no real help on either of these. It's pretty frustrating. My co-worker, Steve, who is taking over for me on this project, wants to put in another box to the mix and see if the problem clears up. If so, then it's the box. Or is it?

If they can't find the problem under load, are they going to fix it when it's isolated and not doing anything? Maybe. But the vendor isn't going to give us a replacement box "just because". It's got to be something. I'm just stumped as to what.

What's frustrating is that it appears to be a networking problem. I get the connection, but getting the contents from the Tomcat instance is exceptionally slow. I suppose, it really appears to be a software problem. Everyone says their stuff is working just fine, but still we have this delay in getting the data.

If it's not the code - and I haven't changed the code in weeks, then it might be the configuration. Nope, I checked that... it's configured exactly right. If it's not the code, and the data loads haven't changed that much, then how likely is it really "within" the box? Not a lot, in my book. But what else could it be?

Not fun.

UPDATE: a reboot of the box fixed it. Something went very wrong with the box. Oh well... can't do much about that.

[5/28] UPDATE: turns out, there's a problem with the stated defaults with Tomcat 6.0.18. In the conf/servlet.xml file there's a maximum number of acceptor threads for the incoming socket connections. It appears that the stated default of 200 was not, in fact, what the default was. Using jConsole, we were able to see that the actual value of maxThreads for the port 8080 connector was 40. We set it in the conf/server.xml:

  <Connector port="8080" protocol="HTTP/1.1"
             connectionTimeout="20000"
             redirectPort="8443"
             maxPostSize="0"
             maxThreads="400" />

and with this (and the automatic change in jConsole) the number of acceptor threads popped up from 40 to 166 and the speed was back. Amazing that the default wasn't what they said. Had that been the case, we would have been fine.

Good lesson to know.

To activate the monitoring for Tomcat assuming it's not already active, you need to add a few command-line options to the CATALINA_OPTS environment variable in either cataling.sh or the startup.sh script:

  export CATALINA_OPTS="-Dcom.sun.monitoring.jmxremote \
      -Dcom.sun.monitoring.jmxremote.port=7999 \
      -Dcom.sun.monitoring.jmxremote.ssl=flase \
      -Dcom.sun.monitoring.jmxremote.authenticate=false"

and then restart the Tomcat server. It's probably not a huge load, but you have to have it in order to connect with jConsole, so it's probably something you need to use unless you know it's not a great idea.

This morning I noticed that GraphicConverter 6.7.2 was out, and I'm becoming a fan of these guys as they are really trying to live up to their name. The release notes say that they are adding support for more file types as well as the links they already have into iPhoto - which I think is great.

It's one of those programs that you don't usually need, but when you need it, it's something you really need. Glad to see it improve.

I noticed this morning that while I was looking at a few houses with Liza, Google Chrome (dev) was updated to 6.0.408.1. That's a good jump as far as Google goes, and it'll be interesting to see what had changed in my daily usage. It's getting better and better, and pretty soon Safari is going to have to sit up and take notice.

OK, it's a little thing, but these days, I'm looking for the little things to help out as these times are tough... but enough of that. One of the things I've been wanting to do for a while is to really improve the quality of my 'favicons' on my HostMonster sites so that it's a little better than my initials and also a little cleaner separation on the different sites so they don't all obviously look like part of one site.

I found a nice little site that had a ton of nice, public domain 16x16 icons perfect for such a use as mine. I had a blast looking at a few pages of icons and picking out a few to clean up a bit and then throw on the sites. It's not a lot, but the effect - to me, is significant.

It's the little things we have to focus on... the biggies are just too daunting to approach these days.

So this morning I got email from easyDNS about the new system they are now rolling out, and it got me thinking about my CVS repository at home, and wanted to check and make sure that the new system would work properly and that I had the right name on the CVSweb root page. So I got to the main page, and clicked into one of the projects and got an rlog error.

Crud.

I hadn't done a lot of checking on the site since I moved it from the old machine that died, and clearly, while the server and it's repositories was fine and intact, the same could not be said for the web access of same. So I had to go digging.

First thing was that I hadn't changed the name on the front page of CVSweb - that was easy and took only a minute. The rlog problem was a little different beast. Actually, it was a hold-over from the NT world where this perl script originally started.

The code I had originally was:

    if ($tag) {
        #can't use -r<tag> as - is allowed in tagnames, but misinterpreated by rlog
        open($fh, 'rlog "' . $filenames . '" 2>nul |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }
    else {
        open($fh, 'rlog -r "' . $filenames . '" 2>nul |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }

and I overlooked the obvious problem for about 10 mins until I realized that the redirection wasn't right. It's not trying to send it to a file, it's trying to dump it. So the correct code looks like:

    if ($tag) {
        #can't use -r<tag> as - is allowed in tagnames, but misinterpreated by rlog
        open($fh, 'rlog "' . $filenames . '" 2>/dev/null |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }
    else {
        open($fh, 'rlog -r "' . $filenames . '" 2>/dev/null |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }

The great thing about Apache is that I found this by looking in the error log. It was telling me that it couldn't create the nul file - but rather than looking for permissions because this is a read-only CGI script, I knew then it was the /dev/null problem.

So... simple to solve and now I'm back in business. This server is backed up by a 1.5TB TimeMachine volume, so I'm not going to have to worry about losing these changes the next time the system dies. Whew!

This morning I noticed that Acorn 2.3.1 was out and the release notes are clear and to the point:

• Fixed a bug where setting the DPI of a JPEG image wasn't always saved correctly.
• Fixed a bug where creating a guide with the contextual menu wouldn't always put it in the right location.
• Fixed a bug where some really old Acorn documents didn't import lines correctly.
• Fixed a bug where the layers lock icon was drawing incorrectly.

I use it almost daily, so it's nice to see things getting addressed. Great package.

Just got a tweet from the Adium crew that 1.4b18 is out fixing Twitter support and Facebook authorization. I don't know that I'll use either of them, but there are a ton of other fixes to this release, and they say they are getting very close to a release for 1.4. Good enough.

Today I got a tweet that Transmit 4.0.3 was released, with a significant list of fixes and additions. It's really quite impressive, and love what they've done with it.

This morning I noticed that MarsEdit 3.0.1 was out and included in the fixes is the bug I reported about using the file:// URL in the template preview! This is really nice because now I don't have to go through apache to get to a file on my box. Very nice, indeed.

Still a great way to post to WordPress... love it to pieces.

UPDATE: I found a little bug in the HTML highlighting in 3.0.1 and sent it to Daniel. The point was that in a pre block, the "less-than-sign" should not be the start of a tag - necessarily, and in one of my code samples, it was in an expression and the rest of the editor window was messed up because of that. I'm not sure how he'll solve it, but I'm sure he'll give it a go.