OK, now is all clear for me .... So it is better not to use sticky_session_force=True, OK, is my actual configuration so
Now is the question : If I don´t have this sticky_session_force=True , what happen with the requests of a session of a server which for any reason have switched off. I mean, the worker who was handeling this session now does not exist, so it is impossible to continue with the same SESSIONID. In this case, another worker will try to manage the request, isn´t it ? It will change the SESSIONID for a new SESSION ID ? For me, in this case, is when my requests have a long delay.... May be I can do a test with few requests and just in the middle shutting down the server with DEBUG in mod_jk, and ty to see the traces. So, in this case I can see where are the delays ? What do you think ? Thank you very much, it is very, very, very helpfully for me 2009/3/13 Rainer Jung <rainer.j...@kippdata.de> > On 13.03.2009 14:08, Toni Menendez Lopez wrote: > >> The behaviour is the one that I explained in the first mail, that when I >> stop one of the servers, I ahve very huge delays to respond to the >> requests of the session that were managed by this server. >> > > OK. > > After reading documentation I think that problem is related with >> parameter : #worker.izonetv.sticky_session_force=1, which if is not >> commented I am not able to launch any call. >> > > Hmm, above you say you have huge delays, here you say you are not able to > launch any call. > > Let me first explain stickyness: > > A request that is forwarded by mod_jk to Tomcat can carry a session id. > Session ids can be part of a request by either setting a so-called session > cookie. This cookie has the name JSESSIONID. Or the session id is added at > the end of the URL in the form ";jsessionid=...". > > Now how does stickyness work: > > - you set the so called jvmRoute in server.xml of your Tomcats. Each Tomcat > gets a different jvmRoute. Say you have jvmRoute node1 and node2. > > - Tomcat automatically adds the jvmRoute to the end of each session id, > whenever it creates a session. The jvmRoute is separated from the rest of > the id by a dot ".". > > - When a mod_jk load balancer operates sticky and it has to forward a > request, that contains a session id, it looks for a dot in this id, and if > it find it, it takes everything after the dot in the id as the name of the > backend. The load balancer then looks for a member worker, whose name is > equal to this jvmRoute. In the above example that would've been node1 or > node2. > > By default any load balancer in mod_jk tries to be sticky, but if it either > cant find the correct worker, or this worker is in error, it chooses another > worker. If you set sticky_session_force, then you tell mod_jk that it should > not try another worker in this case, and instead return an error. > > From your previously send mod_jk log file we can see, that your JBoss sets > a session cookie for the root path "/". That means, this cookie will be sent > fr every request to this host. Since it is a session cookie, this is a good > candidate for desaster, because when you now switch the application, but it > is served by the same host, the browser sends the JBoss session cookie, > although that application will not know this session. > > With sticky_session_force set to true (not the default), when JBoss sends > the redirect to the Tomcat webapp, the browser will send a request for this > Tomcat webapp, but will also send the session cookie from JBoss, because > JBoss set the cookie path to "/". Furthermore JBoss included a node name in > the session id and the load balancer that handles to forwarding to Tomcat > doesn't know about that node, so it can't preserve strict stickyness. > > Usually you don't want sticky_session_force. > > Normally so I comment this parameter otherwise my service does not work, >> > > See above. > > and if I comment I think the mod_jk with requeso of a loose session try >> to go to other worked and it does not sent any error and takes a very >> long delay. >> > > No it didn't in the error log you sent previously. It immediately returned > an error because the request was handeled with forced stickyness, and the > wofrker name given by the session id didn't exist. > > So, for this reason I am trying to investigate the problem with this >> parameter. >> So, focusing in this parameter, the log that I sent to you is with the >> parameter commented, and I found a strange thing. I explain to you : >> My request is the following : http://159.23.98.22/cdp-fe/Trigger.do? >> <http://159.23.98.22/cdp-fe/Trigger.do>..... >> When I send this to apache mod_jk redirects this to my JBOSS application >> ( MCDP worker) and my JBOSS aplication redirect this link to >> http://159.23.98.22/CDP311/...... >> But now mod_jk when receives this second request is trying to send this >> request to MCDP worker again and not to IZONETV worker. >> > > The log shows that mod_jk tries to send it via izonetv: > > It says: > > - Found a wildchar match '/CDP311/*=izonetv' > - Into handler jakarta-servlet worker=izonetv > - found a worker izonetv > - Service error=0 for worker=izonetv > > But it fails, because sticky_session_force was activated > > - service sticky_session=1 id='oK+zmQoPUFefT2vcqTSagg**.MCDP-mifeas02_data' > > and it can't find the worker MCDP-mifeas02_data as part of izonetv: > > - searching worker for session route MCDP-mifeas02_data > > > Any idea why ? >> Sorry, about the updating of mod_jk but is a close platform and I am not >> able to update the mod_jk. >> > > That's very bad. Someone should be able to update it and I do recommend > that (although in this case it wpouldn't solve your problem). > > Thanks again, >> Toni. >> > > Regards, > > Rainer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
