SnapShotInterval problem

[integ]

Hi,
Can someone explain what the SnapShotInterval is during HTTPSession Replication?
I uncommented the default SnapShotInterval specification which was 2000, and found that my sessions were not getting replicated, but as soon as i commented it out , everything was allright.
Ok here's my setup.
I have Apache loadbalancer infront of two jboss3.0.3-tomcat4.1.12 servers T1 & T2
The first request from my login.jsp went to T1. The next request went to T2. The session ids in both were different , from which i inferred that session was not replicated.As soon as i commented the SnapShot interval everything started working.
Why so? And what is the significance of SnapShotInterval?
Thanks

[derry]

Hello!

> Can someone explain what the SnapShotInterval is
> during HTTPSession Replication?

That is easy:
The Tomcat-clustering collects all modified sessions for the given interval and replicates the sessions en-bloc. This can give you a performance-boost if you work with HTML-frames.

> I uncommented the default SnapShotInterval
> specification which was 2000, and found that my
> sessions were not getting replicated, but as soon as
> i commented it out , everything was allright.

That is strange. We use the IntervalSnapshotManager at work without any problem.

> Ok here's my setup.
> I have Apache loadbalancer infront of two
> jboss3.0.3-tomcat4.1.12 servers T1 & T2
> The first request from my login.jsp went to T1. The
> next request went to T2. The session ids in both
> were different , from which i inferred that session
> was not replicated.As soon as i commented the
> SnapShot interval everything started working.
> Why so? And what is the significance of
> SnapShotInterval?

First of all your setup is very bad for session-clustering. You need sticky sessions. That means that all requests from one client go to the same machine (as long as this machine is alive of course ;-) ). You can use the jvmRoute-attribute for this. In your setup request no. 2 goes to the other machine before any session is replicated. That explains why everything works if you use the InstantSnapshotManager.

Another problem is that the Tomcat4.1-clustering code is not up to date. Please use Tomcat4.0 for your tests. I am in progress of porting the changes I made for 4.0 to 4.1.

Hope this helps
Thomas

[brall]

Hi, I am testing a similar clustering setup with mod_jk and apache. So am I to understand that sticky sessions are not enabled by default with the session replication?
Can you explain what you mean about the jvmRoute-attribute?

[derry]

> Hi, I am testing a similar clustering setup with
> mod_jk and apache. So am I to understand that sticky
> sessions are not enabled by default with the session
> replication?

This has nothing to do with the clustering code. It has something to do with your Apache-Tomcat-combo.

> Can you explain what you mean about the
> jvmRoute-attribute?

Google for "apache tomcat jvmroute" for detailed descriptions.

CU
Thomas

[integ]

Hi derry,
I added the following to both the tomcat's server.xml, for T1

and "tomcat2" for T2 , exactly same as in workers.properties file.
However i do not see the jvmRoute in the session id, and the sessions are not "sticky".
My root context is "/" - is that the problem?

http://w6.metronet.com/~wjm/tomcat/2000/Sep/msg00709.html
Anyways i'll try jboss-3.0.3-tomcat4.0.5
-Thanks
Rakesh

[integ]

I set up the jvmROute (it was in tomcat4-service.xml file) and i do see the server name appended to the session id, and sticky sessions are enabled.However i do not get session failover. when i stop T2, i get the following error on T1 : (this is on JBoss_3.0.3_tomcat4.0.5)

19:23:27,517 ERROR [LogInterceptor] EJBException, causedBy:
java.lang.NullPointerException
at java.io.ByteArrayInputStream.(Unknown Source)
at org.jboss.ejb.plugins.CMPClusteredInMemoryPersistenceManager.loadEnti
ty(CMPClusteredInMemoryPersistenceManager.java:352)
at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistence
Manager.java:410)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntityS
ynchronizationInterceptor.java:262)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstance
Interceptor.java:152)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockIntercep
tor.java:107)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
at org.jboss.ejb.Container.invoke(Container.java:712)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.jav
a:102)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.
java:77)
at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:189)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76)
at $Proxy15.remove(Unknown Source)
at org.jboss.ha.httpsession.server.ClusteredHTTPSessionService.removeHtt
pSession(ClusteredHTTPSessionService.java:153)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy232.removeHttpSession(Unknown Source)
at org.jboss.web.catalina.session.ClusterManager.removeSession(ClusterMa
nager.java:496)
at org.jboss.web.catalina.session.ClusterManager.remove(ClusterManager.j
ava:277)
at org.jboss.web.catalina.session.ClusteredSession.setId(ClusteredSessio
n.java:348)
at org.jboss.web.catalina.session.ClusterManager.findSession(ClusterMana
ger.java:209)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:173)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:458
)
at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551)
at java.lang.Thread.run(Unknown Source)
19:23:27,597 ERROR [Engine] Ajp13Processor[8009][4] process: invoke
java.lang.NullPointerException
at org.jboss.web.catalina.session.ClusterManager.findSession(ClusterMana
ger.java:220)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:173)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:458
)
at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551)
at java.lang.Thread.run(Unknown Source)

My guess is that this is because the servername is appended to session id and T2 cannot find it.So does this mean sticky sessions = no session failover ?
I get the same result using JBoss-3.0.3_tomcat-4.1.12.

Non-sticky sessions do work as it is with session replication, except that there is a performance hit.

Ideally i would have liked to have sticky sessions + session failover.

-Rakesh

[derry]

This may be a bug. I will investigate. Thanks for the stacktrace!

CU
Thomas

[integ]

Hi,
Please do post a reply if you fix / figure it out.
Thanks,
Rakesh

[integ]

Please do post a reply in case you fix / figure it out.
Btw after i see the error, i see that the session id is a new one -> session did not replicate.
Thanks,
Rakesh

[integ]

Please do post a reply in case you fix / figure it out.
Btw after i see the error, i see that the session id is a new one -> session did not replicate.
Thanks,
Rakesh

[integ]

Also i found that if i remove from web.xml, i no longer get the error but always gets a new session id ie session doesnt get replicated.

[integ]

Hi,
I think the bug is in ClusterManager.findSession() method..i guess you do not need to call sessions.remove(id) nad removeSession(id) before session.setId() -> setId() anyways removes the session from the local and distributed store using ClusterManager.remove().
The NullPointerException is probably occurring when the SAME session id is being tried to be removed again.

So commenting sessions.remove(id) & removeSession(id) should do the trick.I'll submit this as a bug anyways.
-Rakesh