Quoting Brett Neumeier <[EMAIL PROTECTED]>:
First thanks for your extensive answer.
I was missing the server.xml setting part, that is the jvmRoute attribute, i.e.:
<Engine
name="Standalone"
defaultHost="localhost"
debug="0"
jvmRoute="192.168.1.12:8009">
well reading the following comment could have help ;)
<!-- You should set jvmRoute to support load-balancing via JK/JK2 ie :
<Engine name="Standalone" defaultHost="localhost" debug="0" jvmRoute="jvm1">
-->
With Apache Tomcat/4.1.29 this leads to the extended jsessionid you describe:
0928DE35C1F410D99ABDD4E7A6FA65F6.192.168.1.12:8009
although it did not with one of my older Tomcat instance
jakarta-tomcat-4.1.24-LE-jdk14, which I upgraded to 4.1.29.
Now dealing with two Tomcat/4.1.29 in a group I do not loose sessions anymore
but I am always directed to the same Tomcat instance !
I could successfully force "hot" switching to the unused one by modifiying the
workers2.properties to disable the used channel, setting disabled=1, adding an
increment to attribute ver (not version !) and accessing /jkstatus
This is fine for managing web applications upgrade / maintenance without
application service disruption (I am happy with it), but does not seems to do
Round Robbin load balancing as expected.
Here is my workers2.properties for review, (I am brand new to this JK thing)
# To uncomment while in production
[logger.apache2]
level=DEBUG
[config:]
file=/usr/local/apache2/conf/workers2.properties
debug=0
debugEnv=0
[uriMap:]
info=Maps the requests. Options: debug
debug=0
# Alternate file logger
#[logger.file:0]
#level=DEBUG
#file=${serverRoot}/logs/jk2.log
[shm]
info=Scoreboard. Required for reconfiguration and status with multiprocess servers
file=/usr/local/apache2/logs/jk2.shm
size=1048576
debug=0
disabled=0
[workerEnv:]
info=Global server options
timing=1
debug=0
# Default Native Logger (apache2 or win32 )
# can be overriden to a file logger, useful
# when tracing win32 related issues
#logger=logger.file:0
[lb:lb]
info=Default load balancer.
debug=0
[lb:lb_1]
info=A second load balancer.
debug=0
[channel.socket:localhost:8009]
info=A first channel to tomcat instance on local host
debug=0
tomcatId=localhost:8009
lb_factor=30
group=lb
disabled=0
ver=0
[channel.socket:192.168.1.12:8009]
info=A second channel to tomcat instance on sanbox host
debug=0
tomcatId=192.168.1.12:8009
lb_factor=70
group=lb
disabled=0
ver=0
[status:]
info=Status worker, displays runtime informations
[uri:/jkstatus/*]
info=Display status information and checks the config file for changes.
group=status:
[uri:mill.789.ch/*]
info=mill virtual host
context=/adhoc-crm
group=lb
debug=0
[uri:sandbox.789.ch/*]
info=sandbox virtual host
context=/adhoc-crm
#group=lb_1
group=lb
debug=0
> > The problem is that I have the same behaviour when I simply
> > reload my page in
> > the same Browser instance, jumping from one Tomcat instance
> > to the other as if
> > no javax.servlet.http.HttpSession was defined (jsessionid).
>
> I haven't used JK2, but I know how this works with JK(1) and I think it's
> more or less the same thing.
>
> Some configuration has to be done in JK2, and other configuration has to be
> done in the tomcat instances that are being balanced.
>
> The way that sticky sessions work is that the JSESSIONID cookie value
> provided by Tomcat includes an indicator of which Tomcat instance set the
> cookie. The JK (or JK2) connector looks at this indicator to decide which
> instance should handle new requests. That's pretty simple, right?
>
> In JK2, according to the documentation, there is a "tomcatId" attribute for
> channel.socket configuration stanzas. This attribute is automatically set to
> the local name part of the channel.socket name. So suppose you have a socket
> channel going to a tomcat instance on host flubber.foo.com, port 8080. You
> name the channel:
>
> channel.socket:flubber.foo.com:8080
>
> And the tomcatId gets set to flubber.foo.com:8080 unless you change that
> explicitly. This is the JK2 part of the sticky session configuration.
>
> Now you go to the server.xml configuration file for the tomcat running on
> flubber.foo.com, port 8080. In the Engine element, you set the attribute
> jvmRoute to "flubber.foo.com:8080". When that Tomcat instance sets a
> JSESSIONID cookie, the value will be something like:
>
> 0928DE35C1F410D99ABDD4E7A6FA65F6.flubber.foo.com:8080
>
> Now when the next request comes in from that browser this JSESSIONID cookie
> value will be sent in the request. JK2 will look at the flubber.foo.com:8080
> part of the value, realize that it needs to send the request through that
> channel, and voila, server affinity just like magic!
As a natural french speeker I was pleased to read that "voilą" =:o)
>
> Does that make sense?
>
> It might help other people with the same problem if you report back whether
> this works or not. Like I said, I haven't used JK2 so I don't know for
> sure.
>
I use: jakarta-tomcat-connectors-jk2-2.0.2-src compiled on Linux RedHat 9.0, I
will do further testing/reading next week and report anything new that might
come out.
Regards, Patrick
>
> Cheers,
>
> bn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
