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!
The early bird registration for JFokus 2014, Sweden’s largest developer conference, expires December 31st. Register now and join the fun!
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.
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.