ricky about Kerberos, Apache 2.4 and Solaris 10 (Part II)
Sat, 17.01.2015 13:00
Hi Dr. Avalance, The problem you comment it is usually because the kerberos implementation [...]
Dr.Avalance about Kerberos, Apache 2.4 and Solaris 10 (Part II)
Thu, 15.01.2015 12:58
I appreciate that you wrote this article some time ago now, I've implemented this on a solaris [...]
ricky about SPNEGO/Kerberos in JavaEE
Mon, 05.01.2015 12:57
Hi again dadel, I don't understand you completely. If you use the SPNEGO filter project (th [...]
dadel about SPNEGO/Kerberos in JavaEE
Sun, 04.01.2015 12:55
thanks again for your reply, but there is something that is not clear for me, I'm using glassf [...]
ricky about SPNEGO/Kerberos in JavaEE
Fri, 19.12.2014 23:05
Hi dadel, I wrote two more entries about this subject (PAC and standard solution). Please r [...]
dadel about SPNEGO/Kerberos in JavaEE
Tue, 16.12.2014 14:30
thanks a lot for this useful tutorial, but could you give me a recommendation for authorizatio [...]
ricky about Disappointment with the Web Cryptography API
Sat, 15.11.2014 13:07
The final report of the workshop is public: http://www.w3.org/2012/webcrypto/webcrypto-next [...]
Gregor about Disappointment with the Web Cryptography API
Fri, 07.11.2014 11:13
Hi, I've found your article and I can be just more disappointed than you. I can't believe that [...]
Saturday, May 24. 2014
As you know I am developing a toy project, called couchbase-manager, which is basically a session manager for glassfish application server (version 3 and 4) with the main feature of storing the sessions in a couchbase server. Some days ago the version 0.5 of the manager was released, and today's entry is dedicated to present the new features in the two last versions. (The version 0.4 was released during the upgrading of the blog and, although I prepared the entry, it was never published. I simply forgot about it and then, when I realized about my oversight, I thought it was too late.)
In general this new version 0.5 is much less attractive than the previous one, version 0.4 was a big change inside the manager. I will try to summarize all the the changes below.
After all these changes, new performance tests are going to be presented but, this time, there are changes. The previous performance tests executed requests for session attributes with options: 1x50, 4x50, 20x100 and 20x200 (number of attributes and size of each one, sessions of 50, 200, 2000 and 4000 bytes respectively). In order to test external attributes some tests which manages bigger attributes are needed. Besides a new command line option was added to the web services client application. Now there is a u option which specifies the number of attributes that are accessed in each request. A execution with u=1 means in each update operation only one attribute is requested by the application randomly, but if u=a (the number of attributes to modify is the same of the number of attributes created) all the attributes are modified. This command line option lets us modify the usage ratio of the attributes to force their externalization or not. From now on the tests performed are the following: 4x50-u1, 20x200-u1, 12x12000-u1 and 12x12000-u12. The first two tests are the same tests that were performed before (tests 2 and 4 of the previous versions). The other two are new ones, which use twelve attributes of 12000 bytes (total session size around 140K), one has an attribute usage ratio of 8% (u=1, that means that all attributes are going to be externalized in both configurations) and the other of 100% (u=12, the twelve attributes are always read and, therefore, no one is externalized). Other difference now is that my laptop is configured with the performance governor. I saw that sometimes the numbers varied too much and I checked that the difference was because the frequency set by the governor (I suppose that the load is not big enough to set to maximum frequency with the default ondemand governor in all the tests). The numbers for the four tests are presented below but, because the differences, I am not going to compare them with previous versions.
Starting with the creation operation, the numbers are very similar in all the tests and configurations (except the sticky test where all the external attributes remain integrated in the session, which is slower in the three operations, and I really do not know why). Times should be similar because, more or less, all situations need the same operations against couchbase.
In the update graphic we have some interesting effects. The sticky configuration is not so clearly better, the benefit of saving de-serializations is good for non-sticky configuration. In both configurations times are better if only one attribute is accessed by the application (u=1), in the case that all the attributes are requested (u=12) times are clearly worse. So the externalization feature is quite nice, managing smaller sessions is worthy, and despite of the cost of reading synchronously one attribute. I have a strange feeling with the sticky case with u=12, this case is the worst in all the three operations and I have no reason to explain why (in theory it should be a bit better than the non-sticky test).
Finally the delete operation presents another interesting result. The numbers for all the tests except the one that performs externalization are more or less the same in both configurations, but the test with externalization is remarkably worse. The reason is that, when deleting the session, all the session attributes are accessed to execute possible listeners, so, when they are externalized, all of them have to be read synchronously one by one. Those extra reads make this case almost double the time of the other cases.
The tests show that externalization is a very good feature for the manager. And I feel that in a typical application the externalization would be even worthier (in the test with u=1 all the attributes have the same probability of being accessed by the application, which is not common in the real life). As a final comment I want to say that the performance tests stressed the disk notoriously, there are a lot of sessions being created, deleted and modified and couchbase persists all these changes to disk. Several times I have said that my couchbase environment does not need disk persistence, I think that replication is enough for common JavaEE applications, but couchbase guys seem to be reluctant to provide such configuration. I have read several times that the software is moving to be a complete NoSQL database instead of a cache system. If it is finally true, it is a real pity, because I chose couchbase because it was a cache and not because it was a database. I feel that, with disk persistence imposed, this manager is never going to be fully functional, the best setup is unavailable.
Sunday, November 10. 2013
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:
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!
Friday, June 14. 2013
Going back with my couchbase-manager this week the new version 0.2 has been released. That was long ago when the first version of the manager was made public but I have been waited how several issues evolved. I have to admit that there has not been a lot of movement but I think it is a good time for the second version.
Let's start with the new features in the version:
In the period between the versions there was an attempt to use a different serializer technique. The manager now uses common Java Serializer and it is known that other implementations like Kryo give more performance. Some little tests in order to add Kryo were done but I finally gave up because a lot of internal classes of glassfish require special treatment (objects from cdi/weld, EJBs and so on). Objects of those types need to use the Java Serializer again and I simply thought that the change was not worthy.
The bug about the LDAP realm (the couchbase-manager cannot recover a principal which is stored inside an LDAP realm) was at least updated. Another guy experienced the same problem (but in a completely another way) and the bug was marked to be fixed in version 4.0.1. So I know this is a bug and I will not change the way the manager recovers the principal user from the store when logged.
And finally an annoying behavior still persists when using the non-sticky configuration in the manager. As I have commented several times the deletion of the session cannot be done if the session object had been previously locked (it returns an error). For that reason the only way to delete a session is performing an unlock first and then sending the deletion. Obviously if the session is unlocked weird things could happen and, in my tests, they really happen. I will try to insist on this to the couchbase guys, it should be a way to delete a locked object.
So now you already know, the version 0.2 of the couchbase-manager is out. I encourage all of you to test this new version and comment me or fill a bug in github. I need your comments to check if the manager is minimally usable.
EDIT: I have just discovered that the new glassfish maven repo can be found here. Nice! It is a pity the version 2.0 is just released.
(Page 1 of 3, totaling 9 entries) » next page