While doing a little research for my blogpost “Timeout Configuration in HikariCP, DB2 and MySQL” I stumbled upon a nice feature of the DB2 JDBC-Driver called logWriter.

While doing a little research for my blogpost “Timeout Configuration in HikariCP, DB2 and MySQL” I stumbled upon a nice feature of the DB2 JDBC-Driver called logWriter.
JSF 2.0 introduced it’s own resource handling. One of the disadvantages of this solution is, that referring to an images inside your CSS doesn’t work the common way:
.foo { background-image: url('images/logo.gif'); // doesn't work with JSF 2.x }
You need to use expression language like:
.foo { background-image: url("#{resource['images/logo.gif']}"); }
Now if you are using LESS and don’t want to write this expression over and over again—you need a mixin:
.background-image(@filename) { background-image: e(%("url(#{resource['images:%s']})", @filename)); }
public class FooService { // TODO: remove me! // public final static String NOT_YET = ""; ... }
(Taken from production code)
Michael T. Nygard warns in “Release it” [1] 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).
I recently evaluated whether to use memcached-session-manager [1] for one of our webapps. Although memcached-session-manager bases on spymemcached [2] 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 [3], e.g. KETAMA, is used as hash function. See [4] for details.
In contrast to that, memcached-session-manager doesn’t use hashing at all – it simply “selects the memcached node randomly” [5] (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.