Archive for December, 2013

Logback configuration overhead

The Logback logging framework for Java is great, but one thing I personally miss when I compare it to its venerable Log4j ancestor is the property configurator. Sure, both XML and Groovy are more powerful and there are convenient converters that can produce configuration files based on the old Log4j property files, but what does it cost? XML is much more expensive than simple properties, not to mention loading an entire scripting engine!

I decided to find out. My test case is far from perfect, but it should at least give a hint. It is a simple program. It first measures the time in nanoseconds used for initializing logging; then it allocates memory in a loop in order to force garbage collections. After a few minutes and several collections it triggers a full gc, reports the amount of memory used and sleeps, making it possible to connect and perform additional measurements using jstat or jconsole or some other tool.

I ran the program ten times with each configuration and tested with the simple fallback configuration, which logs to the console, as well as a similar XML and Groovy configuration. The results were not very surprising.

Initialization with the simple configuration was roughly 100 ms. XML configuration required about 200 ms, doubling the startup time. Groovy needed a full second. Heap usage for the application was about 7M with the simple configurator, 10M with XML and 16M with Groovy. Finally, the permanent generation (classes and so on) was 4.4M with the simple configuration, 6.5M with XML and 13M with Groovy.

For an Enterprise application the overhead is trivial, I would worry more about the possible stability issues with a complex scripting engine than with the performance, but for a small application where startup time and footprint matters it makes sense to use a simple method. Perhaps a property-based configurator would be a good addition after all!

Categories: Java

Time to register for JFokus 2014

The early bird registration for JFokus 2014, Sweden’s largest developer conference, expires December 31st. Register now and join the fun!

I'm speaking at JFokus 2014, February 3-5, Stockholm

Categories: Java

DRIVER_POWER_STATE_FAILURE blue screens with Alienware M17x

For quite some time I have had problems with my Alienware M17x when running on batteries. It is easy to reproduce. Every time I turn it off whithout external power connected it hangs and eventually crashes. Apparently I’m not alone in having issues with this model, but the recommended solutions vary greatly.

Finally I found a solution by following Dell’s instructions. It is possible to select PEG in the BIOS and disable the Integrated Intel HD graphics card and leave only the discrete NVidia GPU working. When I did that the problem went away. Apparently the driver failure is related to the Intel card.

The solution has one disadvantage: as the NVidia card uses more power the system drains the battery faster. I prefer that to the crashes, though.

Categories: Windows

Dynamic ports in Windows

Recently we had some issues with a Windows 2008 server. The dynamic port range used by the server did not match the firewall rules. The dynamic port range is used when an application listens on port 0 in order to get an arbitrary free port. I turns out that it is quite easy to find and set the port range:

netsh int ipv4 show dynamicport tcp

The same syntax applies for IPv6 and UDP as well. To set the port range, use a similar command:

netsh int ipv4 set dynamicport tcp start=40000 num=1000

This sets the port range to 40000-41000. The smallest range of ports possible is 255 and the highest port number can’t exceed 65535.

Categories: Networking, Windows