Sunday, November 10. 2013
Couchbase Manager for Glassfish: Version 0.3
Yesterday the version 0.3 of the couchbase-manager was released. As you know it is a little project to manage glassfish sessions inside a couchbase cluster on which I usually spend some time. This version is the first one I feel more or less confortable with it, I think it is starting to be in a mature state. There are mainly two new features in this version: glassfish 4.0 support and, finally, non-sticky configuration is reliable.
As soon as the 0.2 version of my couchbase manager was released the glassfish Oracle group announced the new and bright version 4.0 which, as all of us know, is the reference implementation for JavaEE 7. The couchbase-manager 0.3 works also with glassfish 4.0. I have to admit that the integration was easier than I expected, only some little changes were necessary:
Because now the project is mavenized, just setting the new version of packages web-glue and web-core to version 4.0 was enough to start compiling. Although maven has some objections, library dependencies are managed brilliantly.
Only one class did not compile. The class was the CouchbaseManagerStrategyBuilder which is in charge of the creation of the manager and the one that the glassfish core uses to inject the manager into the application. It seems that the new glassfish has moved some classes from one package to another. In summary, after changing some few lines, the builder compiled again.
In order to manage both versions (glassfish v3 and v4) inside the same project I did some tricks in the maven file (I did not want to separate the code). Now there are two builder classes and two maven profiles, one for v3 and the other for v4, and one class is excluded from compiling depending the profile selected (V3 and V4 maven profiles). It is better explained in the wiki instructions for compiling the project.
Finally in the new glassfish 4.0 the manager is defined in another file.
$ cat META-INF/hk2-locator/default [es.rickyepoderi.couchbasemanager.web.CouchbaseManagerStrategyBuilderV4] contract={com.sun.enterprise.web.PersistenceStrategyBuilder} name=coherence-web
The pity here is that the manager should still be called coherence-web because the reported bug is still present in the new version (nothing has been said about this one).
The second big change is that couchbase server version 2.2.0 fixes the problem about deleting a locked object. That issue forced me to first unlock and then delete the session in previous versions of the manager, and, in a heavy concurrency situation, the two operation technique reported errors. If you check the following bug I opened the issue some time ago and, because couchbase guys did not say anything, I decided to try to fix it by myself. After some hours compiling, checking code, detecting the affected part and fixing it, I realized that the same piece of code had been already patched two months ago. It was a complete waste of time because it was already fixed. I suppose that someone else detected the problem knowing nothing about my bug. I usually work with the community version of couchbase which is one version behind the commercial one. That habit made me fall into that messy situation.
But the result is that finally the manager can delete a session which is locked (passing the cas value). I have tested for a long time the non-sticky configuration and now no concurrency problems are detected. It can be said that now non-sticky solution is reliable.
Nevertheless the new couchbase version has also fixed the touch method. Now when a session is locked touch method results into an error (previously a locked object can be touched without problem). Because there are no unlockAndTouch or similar method in the API I decided to always save the session (cas in non-sticky, set in sticky). It is not a problem cos, after I realized that an attribute can be modified without being put again in the session, the cases when a session was not dirty, and can be touched instead of saved, were really a very little percentage. As a result the previous manager property maxTimeNotSaving has been removed (that property controlled when to save a session which has been only touched for a long time).
Finally I am going to show some times (in ms) of the manager for both configurations. As in the previous entries the configuration is two glassfish v3 in a KVM cluster against a single couchbase installed in my physical laptop. The manager is tested with different session sizes (50, 200, 2000 and 4000 bytes). More or less the numbers are stable and similar to the previous versions except the delete operation, which is slightly slower.
So the summary is that the new version 0.3 of the couchbase-manager is the first one without known problems (I am lying, there is still the LDAP realm problem because of a glassfish bug, but it is a very specific problem). I have more ideas to improve the solution (mainly dealing with attributes as separate objects in order to not save the whole session all the time) but I do not really know when I have the time and the mood to start with such a big change. Just one more comment, in my tests (performance tests mainly) I see that the couchbase server is highly intensive in disk writing (my laptop disk, which is also encrypted, was at 95-100% of utilization rate during tests). As I said several times, in my specific solution persistence to disk is not completely necessary, I think that replicas are enough security for a cache system. But couchbase buckets cannot disable disk persistence (see this forum entry or this another one). I hope that someday this feature was configurable exactly as the replica behavior.
Enjoy version 0.3!
Comments