Michael T. Nygard warns in “Release it”  about the lack of timeouts caused by misconfigured database drivers and connection pools. He argues that if a connection pool gets exhausted when none of its calls return than all others threads get blocked as soon as they require a connection too. His advice is:
Scrutinize Resource Pools
Safe resource pools always limit the time a thread can wait to check out a resource.
(Michael T. Nygard, “Release it”, P. 50)
So I wondered, whether the connection pool HikariCP as well as the JDBC-driver of IBM DB2 and MySQL already ships with default timeouts (and how to adjust them).
When using Eclipse, Maven and Twitter Bootstrap in a web project it’s easy to compile Bootstrap on your own—using Eclipse and Maven. Therefore you can utilize the lesscss-maven-plugin .
Lately I was forced to downgrade a Visual Paradigm Project  from version 10.1 to version 9.
As stated in the Visual Paradigm Know-How Area () this could easily be done by exporting the project to XML (note: not XMI) and re-import it in the older program version. But after doing so all of my artifact’s captions were stick to the upper left corner of the diagrams. There was no chance to move the captions to the correct positions but only to replace the artifacts with new ones. But this is a very time consuming (and annoying) task.
Then I found a more automated solution:
- Open the exported xml-file with a text editor (like Notepad++ ).
- Find and remove all caption-tags.
In Notepad++ this can be done using the function „search & replace“ in combination with the regular expression „“. Replace with an empty string.
- Import the modified xml-file in the older Visual Paradigm installation. Now there are no captions shown at all.
- Select all elements in your diagram (STRG+A) and simply move the selection a bit. As a result all captions appear at their original positions (inside the artifacts).
Please note: this does the the job for me. But I really cannot guarantee for success on bigger or more complex Visual Paradigm Projects. Just give it a try—if you have to downgrade, there’s nothing to loose :-).
I recently evaluated whether to use memcached-session-manager  for one of our webapps. Although memcached-session-manager bases on spymemcached  for communicating with memcached, I was surprised that it uses a significant different algorithm for selecting a memcached instance (out of a pool of given memcached instances) than the native implementation of spymemcached.
Spymemcached selects the instance by calculating a hash of the element’s key and using that hash to determine the instance. Simplified this could be done by compute:
server = serverlist[hash(key)%serverlist.length]
To distribute the elements uniformly on all nodes often Consistent Hashing , e.g. KETAMA, is used as hash function. See  for details.
In contrast to that, memcached-session-manager doesn’t use hashing at all – it simply “selects the memcached node randomly”  (excluding failover nodes). After that the node id is encoded in the session id like 72d9ffcb00d836b3248d8bd95ce2e641-n1.tomcat1 (“n1”). All further accesses are selected by this value.
-  https://code.google.com/p/memcached-session-manager
-  https://code.google.com/p/spymemcached
-  https://en.wikipedia.org/wiki/Consistent_hashing
-  http://www.lastfm.de/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients
-  https://code.google.com/p/memcached-session-manager/wiki/FAQ
Recently I refactored a legacy application which based on a self-implemented logging-framework (I replaced the proprietary logging-code with slf4j). Along that I stumbled over a bunch of anti-patterns I want to discuss further on.
This is the third part of “Logging Anti-Patterns”.