Working on mod_jk
Hello Tomcat dev: Suse 9.2, Apache 2.2.3, mod_jk 1.2.15 I am changing the way mod_jk transfer request to different workers (tomcat instances) in a balanced worker keeping track of the link between session and worker, and I need to use some kind of shared memory inside mod_jk. (I need to share a hashtable). Could you please give me a clue on which set of Apache API calls I could use to do it ? Thank you very much
Re: Working on mod_jk
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. It is impossible for me to use sticky_session or session replication, because I am using an Enhydra Framework inside Tomcat and it handles the session itself. So, I need some kind of "Spanning Tree" scheme. Now I am using the file system to store the hashtable and I want to know if I could use some kind of shared memory inside Apache ... On 8/10/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: Rodrigo Ramele wrote: > Hello Tomcat dev: > > Suse 9.2, Apache 2.2.3, mod_jk 1.2.15 > > I am changing the way mod_jk transfer request to different workers > (tomcat > instances) in a balanced worker keeping track of the link between session > and worker, and I need to use some kind of shared memory inside mod_jk. How do you decide to that a session has timeout? (Guessing that session means jsessionid identified sessions). Cheers Jean-Frederic > (I > need to share a hashtable). Could you please give me a clue on which > set of > Apache API calls I could use to do it ? > > Thank you very much > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working on mod_jk
Rainer, Jean, thank you both of you ! mod_jk already uses shared memory, but since it should >work for apache 1.3 and 2.0/2.2 it does not use apr. If your extensions are >only meant for 2.0/2.2, then have a look at apr: http://apr.apache.org/docs/apr/modules.html I think I only meant it for apache 2.0/2.2 so I will check this ... at least to reach to a working solution. I'm not sure, that I understand your use case. Isn't Enhydra able to include the node info in the cookie, or maybe you are able to set another cookie with the node info, so that the balancer doesn't have to keep state. Exactly, Enhydra is not able to include the node info in the cookie (cannot set something like 8FAB8...23AB.ajp13-server1 as jsessionid), so the request is not properly redirect to the correct worker, and I cannot login. 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? Is a good point. I suppose I could set a timestamp and keep checking it (replicating the session timeout web.xml configuration scheme). Is there any way I could ask the tomcat if some specific jsessionid is longer valid ? I have created the slotmem for that (is in the httpd >branche httpd-proxy-scoreboard). I will check it out, thank you !!! > Suse 9.2, Apache 2.2.3, mod_jk 1.2.15 >> >
Re: Working on mod_jk
Tomcat gurus: I am working with apr table in mod_jk to store the session table but i can't achieve to share the table between differents requests... Someone could give me a tip ? (or a good reference to a site or book related with apache 2 module programming) Thanks a lot !!! On 8/14/06, Rainer Jung <[EMAIL PROTECTED]> wrote: Klaus Wagner wrote: > On Mon, 2006-08-14 at 16:24 +0200, Rainer Jung wrote: > >>Klaus Wagner wrote: >>... >>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 I wanted to adress the original poster :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]