Thursday, August 31, 2006

Throttling Paradox

Who would have thought that you might need to throttle an application server in order to maintain a performance-level contract? I've seen the option inside IIS but couldn't for the life of me think why anyone would want to turn it on. However, in the context of an application that's been through some sort of capacity planning process (so we have a rough idea of how many requests/responses the application can process), and where all requests need their responses within some limited duration (think high-volume/low-latency trading platforms), you can apply throttling to help enforce the performance level. Without throttling, additional requests might be satisfied only to the detriment of other requests already executing on the application server. Ideally, it should be used in conjunction with load-balancing across a cluster of servers, so that throttled requests aren't queued, but rather dispatched to another less-busy machine.

Friday, August 18, 2006


Gone are the days of salting and hashing users' passwords and storing the salt and salted hash next to each other in a database. .NET 2.0's new Rfc2898DeriveBytes class derives a pseudo-random key from a password, salt and a number of iterations - a so-called iterated and salted hash. And, apparently, it's more secure than just hashing a password and salt. More info here.

Wednesday, August 09, 2006


I just noticed while studying for tomorrow's exam that every Java class file begins with the so-called magic number 0xCAFEBABE! Quite funny, especially since the guys who penned it into the class file specification did so before the language was even called Java. You can find more information at Artima.

Thursday, August 03, 2006

.NET 2.0 vs. Java 5

Type erasure, reification and synthetic bridge methods: yuck. I'm stuck on the proverbial consultants' bench so I decided - after 4 years of non-Java development - to upgrade my Java certification to the latest version in just five days. I honestly thought I was going to make the deadline until I hit the section on generics. Now I'm a half-day behind and my head hurts! C# is way easier to grasp, and from the looks of things performs a whole bunch better too (except for the JITed type instance "explosion" if you really care).

Anyway, since Java 5, the Class class in package java.lang is a generic class whose type parameter denotes the type that the Class object represents. Previously, compilers wouldn't let you compare an Integer and a String. Now (since Tiger) they won't even let you compare Integer.class and String.class! It stems back to the fact that (similar to C#) both GenericType<A> and GenericType<B> do not derive from each other, even though type B extends type A. There's a little bit of extra trickery in the Java though, because both GenericType<A> and GenericType<A> extend GenericType<?> (unlike C# where they derive from System.Object.) This means that you CAN compare a GenericType<capture of ? extends Object> with a GenericType<capture of ? extends String>! Madness.