Re: session problems when using mod_jk (1.2.14) load balancing
Hi, I'm using the domain property in the same situation as the one discussed in this thread. Any reason why I shouldn't use the domain property and rely on the worker names instead? Thanks in advance, -- Edgar Alves Rainer Jung wrote: That should not work! The correct way to configure session stickyness is to use jvmRoute (which you already did) and then giving the workers the same names as the jvmRoute. That is instead of bl_worker_dev use dev_alexis and instead of bl_worker_noah use noah_alexis as the worker names. You should check, that the URLs produced by your application include the ;jsessionid=32Characters.jvmRoute or - in case you use cookies - the same info is in your session cookie. mod_jk then automatically strips the jvmRoute part from the session identifier and lloks for a worker of the same name. You will only need to use the domain attribute in case you have a lot of tomcat instances and some of them have the sessions replicated, others not. Then you can give all members of a replication domain the same domain name and mod_jk will know, that in case the correct worker is down, which alternatives are good. Beautiful - worked like a charm. That might take the cake as far as longest question to quickest, shortest answer goes. ha. Thanks a bunch. I might have to gripe about doucmentation in a second (nother thread).. Noah Edgar Alves wrote: Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Hi Mladen, I've used the domain property because it seemed the more general approach (i.e., supports clusters but can be used with a single worker). What this thread got me curious about is if using the domain property in this fashion is officially supported, or on the other hand if it can only be used reliably with clusters. After reading the documentation (http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html), I got the idea that using the domain property with only one worker wouldn't be a trick but another way tell mod_jk which jvmRoute to use: If sticky_session is used, then the domain name is used as session route.. Naming the worker after the intended jvmRoute (even though it used to be the only way) seems more of a trick than explicitly specifying the jvmRoute with the domain property. However, since the same documention mentions that the domain property is used for large systems with clustering, do you know of any side effects (like lower performance) of using this approach as opposed to simply naming the workers after the jvmRoute? -- Edgar Alves Mladen Turk wrote: Edgar Alves wrote: Hi, I'm using the domain property in the same situation as the one discussed in this thread. Any reason why I shouldn't use the domain property and rely on the worker names instead? Domain is supposed to be used with multiple workers sharing the same jvmRoute having session replication between them, thus forming 'cluster groups' to lower the session data replication transfer. You can use the domain, but it's a trick rather then a proper usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves Mott Leroy wrote: Hi - I'm unable to get mod_jk load balancing working. The usual mod_jk setup works just fine, but using a load balancing worker however, is not. [Oddly, my webserver crashed during testing of this, but that could very well be unrelated] The problem is with user sessions. The instances (nodes) do not seem to recognize an already established session with the user and are creating new sessions. It's possible that is a session-stickiness issue, but it appears like the requests are hitting the same instance, just not getting the previously established session. As a result, I can't even reliably login to my application. I created a session listener for debugging purposes and it reports -no- destroyed sessions, but plenty of newly created sessions on both instances that make up the cluster. The session IDs, I noticed, have the jvmRoute name attached to them, which should be a good sign. I have a webserver running Apache (1.3.33), mod_jk (1.2.14), and an application server running the cluster -- 2 instances tomcat (5.0.28) on different ports. I added a unique jvmRoute to both instances in the server.xml: Engine name=Catalina defaultHost=localhost jvmRoute=dev_alexis Engine name=Catalina defaultHost=localhost jvmRoute=noah_alexis My worker.properties loadbalancer settings: worker.list=load_balancer_test worker.load_balancer_test.type=lb worker.load_balancer_test.balance_workers=bl_worker_dev,bl_worker_noah worker.load_balancer_test.sticky_session=true worker.load_balancer_test.sticky_session_force=false worker.bl_worker_dev.type=ajp13 worker.bl_worker_dev.host=alexis worker.bl_worker_dev.port=9003 worker.bl_worker_dev.lbfactor=1 worker.bl_worker_dev.socket_keepalive=1 worker.bl_worker_dev.recycle_timeout=300 worker.bl_worker_noah.type=ajp13 worker.bl_worker_noah.host=alexis worker.bl_worker_noah.port=8063 worker.bl_worker_noah.lbfactor=3 worker.bl_worker_noah.socket_keepalive=1 worker.bl_worker_noah.recycle_timeout=300 Any ideas, things I could try would be much appreciated. - 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]
Re: war files not deploying on redhat
Hi,
I don't know if it was just a typo in your post, but AutoDeploy
should be |autoDeploy.
-- Edgar Alves
|
Paul Warner wrote:
Hello,
I have read the documentation and searched the archives, and whatever I have
found, I have tried, but still my .war files will not unpack and auto deploy.
I
have been running a tomcat server for several months in which the .war files
unpacked and auto-deployed perfectly. But with this new installation, the
Redhat way, with files all over the place, I have not been able to make it
work.
I am using Tomcat 5.0.28 via an rpm on Redhat EL 3. I am accessing the tomcat
server via apache and the jk2 connector. I have the server.xml file configured
with:
Host name=localhost debug=0 appBase=webApps
unpackWARs=true AutoDeploy=true
xmlValidation=false xmlNamespaceAware=false
My application has its context.xml file in the META-INF directory correctly
pointing to the appname, /copse. I have an xml file in
/etc/tomcat5/Catalina/localhost/copse.xml which has in it:
Context docBase=${catalina.home}/build/copse.war
privileged=true antiResourceLocking=false
antiJARLocking=false/Context
The /webapps directory and its contents are owned by tomcat, the tomcat process
owner. root has CATALINA_HOME in its environment, set to /usr/share/tomcat5.
I have a link in /usr/share/tomcat5 to /var/lib/tomcat5/build, which contains
the copse.war file. tomcat has read and write privs for this build/ directory
and all its files.
The differences between my working installation and the 'broken' one seem to
be:
1. root owned the instance of tomcat in the working version, tomcat owns the
instance of tomcat in the broken one
2. file permissions were not all tomcat rw in the broken one, but this I have
fixed now - as far as I know all relevant files are owned by tomcat
3. CATALINA_HOME wasn't set properly for root at first in the 'broken' install
-
but this also has been fixed (I believe). It points to the directory that
holds
all the softlinks to the other directories, such as conf, webapps, build, and
so
on.
I have resorted to unpacking the war file myself, and the application works.
But unpacking by hand is cumbersome and time-consuming. Does anyone have the
(I
presume simple) key to unlock this problem?
Thanks,
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: war files not deploying on redhat
A typo in a post about a typo... :) s/|autodeploy/autoDeploy/ Edgar Alves wrote: Hi, I don't know if it was just a typo in your post, but AutoDeploy should be |autoDeploy. -- Edgar Alves | Paul Warner wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to turn off perssitent sessions in Tomcat 4.1?
Hi, On Tomcat 5.5 you can turn persistent session loading off by setting the SessionManager pathname attribute to . Hope that helps. -- Edgar Alves [EMAIL PROTECTED] wrote: Hi, I am using Apache+Tomcat 4.1.29 for running my application. When I am restarting Tomcat I am getting persistent session loading exception like this: 2004-03-11 13:52:18 StandardManager[] IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.coyote.tomcat4.CoyoteRequestFacade java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.coyote.tomcat4.CoyoteRequestFacade at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.apache.catalina.session.StandardSession.readObject(StandardSession.j ava:1369) I am not using clustering. I want to turn off the session persistence in Tomcat 4.1.29? I have tried so many options with StandardManager in server.xml. But I was not successful. Please help me out in this? Regards AK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSESSIONID and jvmGroup
Hi everyone, I'm trying to setup an Apache server with mod_jk that will be used as load balancer for two Tomcat instances. I've tested my configuration with the cart JSP example and with the sessions example servlet that ship with Tomcat and these have worked fine. To make it work I just had to add the jvmGroup attribute with a different value to the Engine of each Tomcat instance. For instance, the Tomcat server with Engine .. jvmGroup=jvm1 will generate JSESSIONIDs like 0F0C25EC2D11FA13EC4C1E9E36A4E93C.jvm1. mod_jk is correctly using the information in the end of the JSESSIONID value to keep session affinity (or stickyness, in the mod_jk terminology). However, when using an in-house webapp in the same Tomcat installations (where the examples mentioned above work fine), the generated JSESSIONID values are different: Hhft2dCrqsLgZ9ws1jpApprJ. It seems (to my untrained eyes, at least) that something in our webapp is causing a different JSESSIONID generation mechanism to be used. Any ideas on where/what to look for and how to have the JSESSIONIDs always tagged with the value of the jvmGroup attribute would be greatly appreciated. Thanks in advance, -- Edgar Alves - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSESSIONID and jvmGroup
Hi again, I've just found out that the WEB-INF/web.xml for our webapp was using the Enydra standard session manager. No wonder the JSESSIONIDs weren't similar. Anyway, I thought that the appending of .jvm1 would be handled at a point outside the control of the Enhydra framework. Anyway, sorry about the line noise. -- Edgar Alves Edgar Alves wrote: Hi everyone, I'm trying to setup an Apache server with mod_jk that will be used as load balancer for two Tomcat instances. I've tested my configuration with the cart JSP example and with the sessions example servlet that ship with Tomcat and these have worked fine. To make it work I just had to add the jvmGroup attribute with a different value to the Engine of each Tomcat instance. For instance, the Tomcat server with Engine .. jvmGroup=jvm1 will generate JSESSIONIDs like 0F0C25EC2D11FA13EC4C1E9E36A4E93C.jvm1. mod_jk is correctly using the information in the end of the JSESSIONID value to keep session affinity (or stickyness, in the mod_jk terminology). However, when using an in-house webapp in the same Tomcat installations (where the examples mentioned above work fine), the generated JSESSIONID values are different: Hhft2dCrqsLgZ9ws1jpApprJ. It seems (to my untrained eyes, at least) that something in our webapp is causing a different JSESSIONID generation mechanism to be used. Any ideas on where/what to look for and how to have the JSESSIONIDs always tagged with the value of the jvmGroup attribute would be greatly appreciated. Thanks in advance, -- Edgar Alves - 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]
