Re: svn lock: /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/http/res/LocalStrings_fr.properties
On Thu, 2006-07-20 at 12:18 +, [EMAIL PROTECTED] wrote: > Author: mturk > Comment: > SVN Propset in progress. > > Locked paths: > > tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/http/res/LocalStrings_fr.properties > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > funny ... what's the purpose of this? regards Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working on mod_jk
On Fri, 2006-08-11 at 09:51 +0200, Jean-frederic Clere wrote: > Rodrigo Ramele wrote: > > > Hello Jean, ! > > Thanks for answeringI didn't explain myself very well. I meant: I > > need > > to keep track each one of the JSESSIONID and the worker where the > > 'Set-Cookie' header comes from, so when a new Request with this cookie > > arrives again (from the browser) i would properly redirect it to the > > correct > > worker, where the tomcat that created this cookies is connected. > > Yep. My question was: How do you decide in httpd that a JSESSIONID is > not longer valid to remove the corresponding element in your hashtable? As having this done for another project the solution is quite simple: 1. for every id in the hashtable record a timestamp/counter 2. (re)set the timecounter every time the sessionid shows up (both directions would be great - else user->server is sufficent) 3. make the sessiontimeout "managable" meaning an option in the config file. Normally the Applaction Layer Sessions have defined timeouts. Otherwise use a higher value then the Application reasonable does or as high as possible without doing too much pressure on the system. 4. the tricky part: have a) a watchdog that clears invalid sessions in idle time or b) clear sessions before looking for them (causes some performance issues) regards Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working on mod_jk
On Mon, 2006-08-14 at 16:24 +0200, Rainer Jung wrote: > Klaus Wagner wrote: > ... > > 4. the tricky part: have a) a watchdog that clears invalid sessions in > > idle time or b) clear sessions before looking for them (causes some > > performance issues) > > > > If you really, really want to do this, for the watchdog you can enhance > the existing maintain methods. There is already a mechanism that calls > the maintain methods during a request only if the last call to it is > longer ago than worker.maintain seconds (Default: 60 seconds). The > method is called during request work, so it must be stable and fast I don't want to do anything, just giving impressions how I would do if I had to do but thanks. Good to know that there is pretty much everything there that would be needed. regards Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible mod_jk "feature"
Here my impressions of the situation from an serveradmin perspective. On Wed, 2006-08-23 at 17:08 +0200, Rainer Jung wrote: > I still don't have a consistent idea what happened around the firewall: > > - silently dropping is not expected apart from a deny rule, but deny > will not be the rule that had been applied to the apache-tomcat connection. state keeping firewalls have timeouts. If the firewalltimeouts are lower that keepalive timeouts there is a possibility that the firewall invalidates the connection - afterwards it will drop any related packet. Another possibility would be a firewall that is forgetting states which would be clearly a bug. > > - only shutting down one side of an established (!) connection seems broken I don't think this is going to happen, but here is the reason why tomcat is in the worse situation: client ---request---> apache apache tries to use the stale connection and realizes that this is broken de facto immediately (socket error) tomcat on the other hand is not really notified (execpt when the kernel marks the connection as stale (timeout) AND tomcat tries to read from or poll/select the connections state) > - no answers yet about using TCP keep-alive should help in most cases imho regards Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
