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.
Posts Tagged ‘Java’
A Less Mixin for JSF 2 Resource Handling
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)
Timeout Configuration in HikariCP, DB2 and MySQL
Motivation
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).
Instance Selection Algorithm: spymemcached vs. memcached-session-manager
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
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.
Memcached-Session-Manager
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.
Reference
- [1] https://code.google.com/p/memcached-session-manager
- [2] https://code.google.com/p/spymemcached
- [3] https://en.wikipedia.org/wiki/Consistent_hashing
- [4] http://www.lastfm.de/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients
- [5] https://code.google.com/p/memcached-session-manager/wiki/FAQ