session replication works well with both of thesetomcats (the ones bundled with jboss)!!! (using javagroups.jar v2.1, tomcat-javagroups.jar and UDP protocol stack for InMemoryReplicationManager)

i've tried all possible combinations with bothjboss (and their tomcat4-service.xml) but seems like JBoss handles by itself session replication(through jbossha-httpsession.sar) witn no success (andworst, with no logs, traces that explain such a session replication problem)

I have gotten jbossha-httpsession.sar to work a bit on a windows 2000 box. So far, my testing has been with two different server instances running on the same box. The session does replicate back and forth for me. Placing the 'distributable' in the web.xml file did not break anything.

I have a different problem (described in my thread earlier today). Session affinity is broken for me because I am using the Tomcat supplied isapi_redirect.dll for forwarding requests from IIS to JBoss (it's handshake is the same as the apache redirector I think). That redirector requires that Tomcat append a token at the end of each JsessionId cookie -- the token being a name unique to the server and configured using a jvmRoute setting in the server configuration. You can see the token when you do a session.getID().

I can see in the code for org.jboss.ha.httpsession.server.ClusteredHTTPSessionService.java that it has a method called generateSessionId() which makes no attempt to append the token. I am tempted to go in and patch my copy of this module (as well as altering org.jboss.web.catalina.EmbeddedCatalinaServiceSX to send in a jvmRoute property) to fix the problem but right now I am waiting to see if we're going to use this at our organization (for other reasons) and to see what Sacha says about it.

DON'T DO THIS in org.jboss.ha.httpsession.server.ClusteredHTTPSessionService.java!!!

This service is used by Tomcat AND Jetty - so if you wan't to change something please do it in the Tomcat-service code. I think the thing with jvmRoute is a BUG in the tomcat-clustering code - so it is my job to iron it out... ;-) Any patch from your side is welcome. If you have one send it to me.

Today I am having trouble building both the JBoss3_0_1RC1 branch and the HEAD branch -- getting an error in javax.security.auth.login.LoginContext.java module (can't resolve symbol '.module' in class javax.security.auth.login.AppConfigurationEntry) Not sure if it's because I'm now using jdk1.4.1RC or what.

The clustering folder builds fine, as does the catalina folder (except it only generates the jboss-service.xml file). Are there specific deployable modules that I could build and place in my JBoss3_0_1RC1 deployment?

For some reason, I can't get the JBoss3_0_1RC1 branch built today -- getting an undefined symbol in javax.security.auth.login.LoginContext -- can't find '.module' in the class AppConfigurationEntry. Same problem building HEAD. I've recently switched to jdk1.4.1RC so don't know if that's my problem.

However if could point me to which modules have changed, perhaps I can build those and deploy them into my regular RC1 release. cluster builds but the catalina folder doesn't build the tomcat4-service.jar

that means,- load balancing and session afinity seem now to workthe right way(i.e. SessionIds Sad06NhOOs91G9qEk+gflw**.server1)- launch the 2 clustered-servers and fill the session of one of them: we'll call this server "server1"(although i have debug="99" in most xml i cannotsee any session replication logs :-(- stop server1- try to continue filling your session (using the samesessionId)- yujuuuuu !, session is being replicated(although i still haven't got any logs that confirms it)- now launch again the dead server ("server1")when it finishes launching it should replicate thecurrent session in server2 but...- try to continue filling your session:wops !, a new session ? where did my shopping cart go ?

and when I shut serverOne off, the same exact session continues to be served from serverTwo! Yeah!

Fail Back seems to work for me. If I shut serverOne down, then hit the site in a session a few times (being served from serverTwo), then bring serverOne back up, the session continues to live -- it has a mind of it's own about whether it continues on ServerOne or ServerTwo but it does continue. Browser sessions that never were refreshed while serverOne was down will continue to be served with the correct session on serverOne after it comes back up. The first browser in after a server comes back up seems to be served from the failover server then bounces back to it's original server on the second refresh.

I'm scratching my head over the load balancing now -- the isapi_redirector.dll doesn't seem to round robin every other new session anymore when hitting a clustered site. It seems to stick with one of the servers for a while -- no matter if I start a dozen or so new web browsers. I'll have to look at it further. After either a period of time or when a server goes down and up, the entire load is directed to the other server. I'll do more testing.

> Fail Back seems to work for me. [...] it has a mind of> it's own about whether it continues on ServerOne or> ServerTwo but it does continue. Browser sessions that> never were refreshed while serverOne was down will> continue to be served with the correct session on> serverOne after it comes back up.> The first browser in after a server comes back up seems > to be served from the failover server then bounces back > to it's original server on the second refresh.

Session fail back doesn't work for me, even for browsersessions that never were refreshed while server1 was down ! in all cases a new session is created in server1 !!

>i'm scratching my head over the load balancing now -- >the isapi_redirector.dll doesn't seem to round robin >every other new session anymore when hitting a clustered >site. It seems to stick with one of the servers for a >while -- no matter if I start a dozen or so new web >browsers. I'll have to look at it further.

The only difference i appreciate between our environmentsmust be isapi_redirector.dll's (i'm using mod_jk) load balancing & sticky session behaviour.mod_jk manages load balancing by means of round robinfor every new session created to an alternative server).(in my experience sticky balancing does affect the"quality" of the new session round robin although i don't know how)

Do you have some logs that explicit the fact that whenserverOne returns to live somehow it copies the clusteredHTTP session ? Anyone does ?

The fact that server1 doesn't get the session back from server2 may be a bug.

The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

I will have a look into this. Jetty clustering code is affected by this, too.

The fact that server1 doesn't get the session back from server2 may be a bug.

The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

I will have a look into this. Jetty clustering code is affected by this, too.

The fact that server1 doesn't get the session back from server2 may be a bug.

The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

I will have a look into this. Jetty clustering code is affected by this, too.

The fact that server1 doesn't get the session back from server2 may be a bug.

The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

I will have a look into this. Jetty clustering code is affected by this, too.