Couchbase Manager for Glassfish: Version 0.2
Friday, June 14 2013
HTTP Headers and JavaEE
Saturday, June 1 2013
OCSP Java Bug (Part II)
Saturday, May 18 2013
Debian 7.0 released!
Sunday, May 5 2013
Glassfish HA using EJB
Sunday, April 7 2013
BUG in Java OCSP Implementation (PKIX)?
Friday, March 15 2013
SPNEGO/Kerberos in JavaEE (spnego.java.net)
Sunday, March 3 2013
Saturday, February 16 2013
SPNEGO/Kerberos in JavaEE (PAC)
Saturday, February 2 2013
SPNEGO/Kerberos in JavaEE
Friday, January 18 2013
MAAK WEBSITE about Glassfish HA using EJB
Mon, 17.06.2013 17:51
Wonderful article! We are linking to this great article on our site. Keep up the good writing.
ricky about SPNEGO/Kerberos in JavaEE
Fri, 07.06.2013 17:56
Hi Aleksadar, It depends on what library you're using. In case of the spnego filter I'm usi [...]
Aleksadar Lukic about SPNEGO/Kerberos in JavaEE
Thu, 06.06.2013 15:16
I set tomcat 7 with spnego on red hat machine and automatic authentification on windows server [...]
ricky about BUG in Java OCSP Implementation (PKIX)?
Tue, 04.06.2013 15:39
Hi Simon, I wrote another entry about this issue and, at least, another one is coming. I'm [...]
Simon Gerber about BUG in Java OCSP Implementation (PKIX)?
Mon, 03.06.2013 15:07
Hey Ricky Thanks for the cool writeup! Did you get any respone concerning the JAVA bug rep [...]
Blind Bat about Debian Multiarch
Tue, 28.05.2013 05:48
Do you really want your blog to be in light-grey on a white background? Its so hard to read [...]
ricky about Debian Multiarch
Thu, 04.04.2013 10:13
Hi Rulet, Usually this is a bug in the distribution packages, I suppose you're using ubuntu [...]
rulet about Debian Multiarch
Wed, 03.04.2013 18:05
Whem trying to install libasound2:i386 it gives an error that /usr/share/alsa/alsa.conf cannot [...]
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.
Saturday, September 29. 2012
After the announce for the couchbase-manager-0.1 this post is going to show how it deals with some JavaEE sample applications. Before the releasing I made it work with some of them in order to make the manager compatible with part of the typical JavaEE elements (EJB, CDI, JSF Managed Beans, JavaEE security and so on). As it is said in the release notes for 0.1 version the manager is still not fully tested but, at least, some applications work.
JSF Beans, CDI and EJBs.
JSF and EJB are two important technologies in the JavaEE world and I recovered the old CertSecurityCustom project for the occasion. If you remember that project lets us login using a certificate or a typical username/password form and checks the user against an LDAP repository. The project mainly consists in a EJB and a session JSF bean. After making all the objects to implement the Serializable interface and fixing some issues with the manager (mainly the memcached transcoder must use a special glassfish Input/Output object stream) it worked like a champ.
Here I realized another thing, an application can get and attribute from the session, change it and not set it back (it is supposed that it is the same object and no set is necessary). So in 0.1 version the manager marks as dirty any session when any attribute is got (that means mainly all sessions are always set or cas, for the moment touch is only used when the attribute retrieved is a simple object -Integer, String and some other classes that cannot be changed internally-).
Besides I inject the JSF bean using CDI (@Named) and typical bean (@ManagedBean), and same with the ldap ejb (@EJB and @Inject). The four combinations worked after the commented changes.
JavaEE security is another hard issue I wanted to be functional in the first realease. The application that I chose was the CertSecurityJavaEE project (the second example in the certificate login series which uses again an LDAP server but doing standard JavaEE security).
More problems here were found. Glassfish declares the principal property of the session as transient (keyword that means the property has to not be serialized and therefore saved). Looking at the replicated glassfish implementation, I saw that only the username property is kept replicated. If the session is used in another server (in which the user did not logged in), the replicated implementation logs the used silently using a special method in the realm (createFailOveredPrincipal). I did the same trick. Now the manager session has a username property that is saved in couchbase with the other data, when the session is filled that property is checked and if it is different from the principal in the session (null mainly) the principal is recovered from the realm calling the same method.
That was very nice but it didn't work with the LDAP realm. I opened a bug with the issue but silence is the only answer til the moment (some collaboration please!). Changing the realm from ldap implementation to file (users and groups are stored in a plain file) my solution works as expected. The user logins to one application server and if it changes (non-sticky load balancing or a failure in sticky configuration) the user is logged in the background. Take in mind that this happens the first time the user access a new server (the manager sees the principal is null but the username is filled and it uses the realm to reassemble the principals of the logged user).
With all those changes my little application started working using the couchbase manager.
Java Pet Store 2.0EA
Finally I tested the typical Pet Store application. This application was for along time a kind of a reference application for JavaEE, now it is abandoned and its last version 2.0EA is only JavaEE4 compliant (not 5). Nevertheless I think it is a good test cos it mixes several technologies of the JavaEE specification.
With the pet store application I faced with a glassfish issue when using mod_jk and mod_deflate in the apache. But after fixing that issue the manager started to work smoothly. All the session beans were transformed into serializable objects (in version 0.1 the manager uses standard java serialization to convert the session into a byte array, that means all the objects that are going to be saved inside the session should implement the Serializable interface).
And here it is the video. First the custom ldap login application is shown (the application refused to change me from one server to the other but finally it did), you can see how the couchbase console shows one session and, as soon as I log out, the session disappeared. Then the standard JavaEE security application is accessed. Both servers maintain my logged session using the file realm. Finally I enter Pet Store application and click over some of the pages which work smoothly.
Well, the couchbase-manager-0.1 is working with some (more or less) complicated JavaEE applications. I am conscious that there are more tests to do, and that is the reason to release the first version, let more people testing it. If anyone of you is interested in the manager please install it and test it with your applications (use github or this blog to report issues). Of course I guarantee nothing about the fix.
Saturday, August 11. 2012
All the last entries in the blog are dealing with my new idea about the couchbase-manager whose first version was released some days ago. I think the current status is good enough to release a first testing version. The main problem is that I have tested it only with a few real applications and that makes me extremely cautious about the quality. For the moment the last weekend I did another test I was eager to do: running the web services test application with an auto-failover three node couchbase cluster.
The demo environment is very similar to the commented in the full HA glassfish setup entry:
So the idea is simple. I run a long multi-thread test that uses some sessions and, while everything is running, the couchbase server installed in my laptop is stopped. Theoretically some of the client threads will begin to fail (the ones which were using the crashed server) but, in 30 seconds, couchbase will fail over the downed node and re-balance the situation with the two remaining servers. All the clients should recover their sessions and run again without any problem. Let's see the video.
As you see the couchbase console shows a three server cluster. And immediately the client program is executed with the following options:
$ time java -cp . es.rickyepoderi.managertest.client.Test \ -b "http://192.168.122.21/manager-test/SessionTest?wsdl" \ -t 8 -ci 100 -ts 2000 -d
That means that eight threads (clients) will create a session and perform a update or a refresh every two seconds for a hundred times, at the end the session will be invalidated (that gives me 200 seconds to do the video ). Once all the threads are doing the operations the couchbase deployed in my laptop is stopped. In that moment some clients start to fail (for example child thread 18 or 19). The console marks the server as down and the 30 seconds auto-failover timeout is triggered. While the affected clients keep failing, the failover for the crashed server is automatically performed (it is marked in the console with the alarm icon). From that moment the failed clients recover the session from another server and they continue smoothly (the session is not created again, the same session is recovered!). The done! button in the console is clicked to acknowledge the situation and then the downed server is re-started. The console immediately informs about the new situation and, clicking manually the add back button, the cluster is reestablished. Once the three nodes are again back in the cluster the sessions are manually re-balanced inside the new cluster topology (rebalance button). In this point the only weird thing happens, some clients fail again (it is like in the re-balancing process some errors could happen). The exception given by the manager is the following:
java.lang.IllegalStateException: EXCEPTION at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.doSessionLoad(CouchbaseManager.java:715) at es.rickyepoderi.couchbasemanager.session.CouchbaseWrapperSession.doLoad(CouchbaseWrapperSession.java:383) at es.rickyepoderi.couchbasemanager.session.CouchbaseWrapperSession.lockForeground(CouchbaseWrapperSession.java:478) at org.apache.catalina.connector.Request.lockSession(Request.java:4165) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:312) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ajp.AjpProcessorTask.invokeAdapter(AjpProcessorTask.java:125) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:679) Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException: Cancelled at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:103) at es.rickyepoderi.couchbasemanager.couchbase.ClientResult.createClientResultObject(ClientResult.java:103) at es.rickyepoderi.couchbasemanager.couchbase.ClientRequest.waitForCompletion(ClientRequest.java:259) at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.doSessionLoad(CouchbaseManager.java:696) ... 22 more Caused by: java.lang.RuntimeException: Cancelled ... 26 more
So the operation was canceled. Maybe some re-tries would be necessary (in case of a cancel) but that kind of things complicate so much the implementation that, for the moment, I am not going to do it (besides the re-try could also be performed by the couchbase/spymemcached client ). But it could be said that it is working and, more important, it is working well.
I love it when a plan comes together!
(Page 1 of 3, totaling 7 entries) » next page