-
1. Re: HTTP in-memory session replication
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.
Bob -
2. Re: HTTP in-memory session replication
Hello!
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.
CU
Thomas -
3. Re: HTTP in-memory session replication
The clustering code now respects jvmRoute - the patch is in HEAD and Branch_3_0...
Please try it...
CU
Thomas -
4. Re: HTTP in-memory session replication
Great!
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?
Thank you.
Bob -
5. Re: HTTP in-memory session replication
Thanks!
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
Bob -
6. Re: HTTP in-memory session replication
Hi
>The clustering code now respects jvmRoute - the patch is >in HEAD and Branch_3_0...
>Please try it...
I've just try it out, ... but
unfortunately,
that did not solve my initial problem
(session still doesn't get replicated :-(
Thanks for your interest -
7. Re: HTTP in-memory session replication
Seems the new sources solved my problem
but ...
session failback isn't yet achieved !
that means,
- load balancing and session afinity seem now to work
the 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 cannot
see any session replication logs :-(
- stop server1
- try to continue filling your session (using the same
sessionId)
- 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 the
current session in server2 but...
- try to continue filling your session:
wops !, a new session ? where did my shopping cart go ?
is it session failback already implemented ?
Thanks -
8. Re: HTTP in-memory session replication
One more thought ...
i was so happy to see that, finally, the session get
replicated that i deleted jvmRoute="worker_as_in_workers.properties_name"
from tomcat4-service.xml to force the lost of
session affinity
i believed that (as session was now replicated) session
affinity was useless (without taking into accout performance boost) from a theoric point of view.
but, i was very disappointed to see that losing session
affinity also causes to loose session replication :-(
so, my final situation is:
session affinity + HTTP in-memory session replication + without session failback ! :-(
is there such a way to improve this situation ? -
9. Re: HTTP in-memory session replication
With the fix, Sticky load balancing now works for me too.
I am able to see the sessionid with the appended jvmRoute:
6QSANdMh-X1ZOJYTWfxDgA**.serverOne
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.
Bob -
10. Re: HTTP in-memory session replication
Thanks for your answer,
> 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 browser
sessions 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 environments
must be isapi_redirector.dll's (i'm using mod_jk) load balancing & sticky session behaviour.
mod_jk manages load balancing by means of round robin
for 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 when
serverOne returns to live somehow it copies the clustered
HTTP session ? Anyone does ? -
11. Re: HTTP in-memory session replication
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.
CU
Thomas -
12. Re: HTTP in-memory session replication
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.
CU
Thomas -
13. Re: HTTP in-memory session replication
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.
CU
Thomas -
14. Re: HTTP in-memory session replication
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.
CU
Thomas