There’s been a lot of discussion around the release of Tornado, the web server that powers FriendFeed, which was recently Open Sourced.

Most of this discussion revolves around the technical merits of Tornado; whether other platforms are quicker, or whether it’s too limited.  Whilst interesting, I think that many of these discussions are rather missing the point.

What I find interesting about FriendFeed is that it was built primarily because of the requirements of the way the FriendFeed site works.  To give an overview without getting too much into the technical details, the difference is in the way real-time data is updated.
The way pretty much every other website works with regards to updating data is to poll for updates at regular intervals.  FriendFeed works differently; they create a connection to the server, and sit there waiting for an update.  When an update does happen, it displays immediately, because there’s no need to wait for a polling update to run.
A website that works like this, with every user having a connection open waiting for an update, isn’t feasible to create when using a mainstream web server (Apache, Nginx, IIS), because they are designed with the older ‘open a connection, send the data, close the connection’ way of working in mind.

I expect that as desktop software dies out and everything moves to a web-based ’software-as-a-service’ approach it will become increasingly common that parts of the site will run on custom-written software.  The days of the dominance of Apache are over, not because another better webserver daemon has come along, but because with increasingly complex webapps one size no longer fits all.

apache, tornado

Many networks have hosts which aren’t directly accessible via SSH, but have to be connected to via another host.  This can be a pain, especially when one wishes to use scp or sftp.

For a while now I’ve been using the following in my SSH .config file to allow me to SSH ‘directly’ to such hosts:

Host ultimate-destination-name
  ProxyCommand ssh -q intermediary-host nc %h %p $*
  HostName ultimate-destination-host

Where ‘ultimate-destination-name’ is the friendly name for the remote host – this probably shouldn’t be a hostname to avoid confusion, ‘intermediary-host’ is the Internet-accessible host to connect via, and ‘ultimate-destination-host’ is the local hostname/IP for the destination machine, ie what you’d type after ssh once logged into the intermediary host.
You’ll need netcat installed on the intermediary host for this to work.

Apart from the obvious advantage of being able to just type ’ssh foo’ to get straight to host foo, this method also allows you to use your local ssh keys without any sort of trust arrangement.

netcat, ssh, Tips

There’s a superb post over at the Moserware blog entitled ‘The First Few Milliseconds of an HTTPS Connection‘.  I’d definitely recommend it to anyone even vaguely interested in what keeps everyones confidential data secure.

, https, ssl, tls

For obvious reasons everyone is looking to make cost savings at the moment, and for inspiration you can look to the French Gendarmerie, who have saved millions of Euros as part of a transition to Linux.

 “A report published by the European Commission’s Open Source Observatory provides some details from a recent presentation given by Gendarmerie Lieutenant-Colonel Xavier Guimard, who says that the Gendarmerie has been able to reduced its annual IT budget by 70 percent without having to reduce its capabilities.”

Read the full story over at Ars Technica.

gendarmerie, Linux, recession

After spending far too much time investigating a particularly thorny problem with a Java app, here’s a brief guide for anyone else stuck in the same predicament.

First, find some general information on the environment:

Show the JVM system properties

jinfo [pid]

Show heap space usage

jmap -heap [pid]

Show object memory usage

jmap -histo [pid]

Next, find out some more specifics about what the app is actually doing:

Take a thread dump

pkill -3 java; sleep 5; pkill -3 java

We do the kill -3 twice to show if threads are stuck in a particular state – add more as required.  The thread dump is written to stdout for the java process.  This will be catalina.out for a Tomcat app, elsewhere for others, check the init script for clues.

Take a stack trace

jstack [pid]

For apps using JNI you can take a mixed-mode trace by doing

jstack -m [pid]

and piping the output through c++filt. On Solaris, c++filt can be obtained as part of Sun Studio Express

Hopefully by this point you should have enough data to at least give you some clues as to where the problems are occuring.

Java, jvm