Version 0.1

This is the first version of the couchbase-manager. Currently it is not in a production quality state and this version is mainly for testing purposes (the more people testing it the better). This version was developed using glassfish 3.1.2 although it may works in any 3.1.x version.

The branch for this version is located here. Download and installation instructions are detailed in the following page. The couchbase-manager-0.1.jar library can also be download from this site but remember it is absolutely useless without glassfish and all the rest of dependencies.

More information about the manager and its development can be found in this blog.

Main Features

The main features of the manager are the following:

• The couchbase manager is a session manager for glassfish that uses a couchbase repository to store Servlet sessions. The main idea is all the responsibility depends on couchbase (locking, expiration and so on).

• The sessions are retrieved and stored in couchbase inside the lockForeground and unlockForeground session methods (also in the background alternatives).

• This version manages a sticky and a non-sticky way of working. The sticky configuration takes the advantage of knowing there is only one server managing the session and, therefore, some accesses to couchbase and the locking part are saved. Currently this configuration is the recommended (although non-sticky is the default one for security).

• The manager implements all the operations against couchbase asynchronously but only the saving part (the set or touch that is doing in the unlock method) is really done in the background.

• Couchbase error handling is done in every operation. When an operation fails the session is marked in ERROR state (take in mind that a background operation can fail without a direct error presented to the user). Any session in that condition should be re-read from couchbase.

Current Status

Only some sample applications have been tested with the couchbase manager. Currently the JavaEE technologies that have been checked are the following (but not very thoroughly tested):

• Common Servlet/JSP applications.

• JSF applications (injecting the beans using CDI and normal ManagedBeans annotations).

• EJB (again injected in the session using @Inject and @EJB annotations).

• JavaEE security (JavaEE security using a file realm).

Known Issues

• When undeploying or stopping the glassfish server the exception shown below is thrown. For different reasons the manager is using the coherence-web name (mainly because no other name worked, an that existing name was re-used). It seems that glassfish call a coherence class when unloading the manager which is obviously not found. This issue produces later annoying effects (the manager is badly unloaded).

java.lang.ClassNotFoundException: com.tangosol.net.CacheFactory at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1509) at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359) at com.sun.enterprise.web.WebApplication.stopCoherenceWeb(WebApplication.java:622) at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:171) at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169) at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302) at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:329) at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:998) at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:1970) at org.glassfish.deployment.admin.DisableCommand.execute(DisableCommand.java:287) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1066) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354) 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.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)

• The manager cannot maintain a principal which has been logged using an LDAP realm. This issue needs further investigation but a glassfish bug can be involved.

• In non-sticky configuration if the level of concurrency is high enough some exceptions could be thrown at invalidating (deleting) a session. Cos couchbase api has no unlockAndDelete operation the manager is forced to first unlock and then delete the session, in high concurrency situations errors are reported.