Re: parallel deployment: multiple applications responding
On 27/02/2012 22:23, Aristedes Maniatis wrote: > On 28/02/12 12:14 AM, Christopher Schultz wrote: > Chuck, > > On 2/26/12 11:29 PM, Caldarale, Charles R wrote: >>>>> From: Aristedes Maniatis [mailto:amania...@apache.org] Subject: >>>>> Re: parallel deployment: multiple applications responding >>>> >>>>> What happens if our application defines a static class or other >>>>> resource? >>>> >>>> Not sure what you mean by "static class", unless you're referring >>>> to an inner class. Regardless, each parallel deployment uses a >>>> separate classloader, so the webapp instances cannot interfere >>>> with each other. > > I'm sure he means a class with a static method that returns a shared > object (aka singleton, etc.). > >> Yes of course. I mispoke earlier. > > >>>> However, if you've placed classes in a shared library (e.g., >>>> Tomcat's lib directory), anything in there will be shared by all >>>> webapps. You must be very, very careful when utilizing shared >>>> classes, since that can easily lead to unexpected data leakage >>>> between webapps (not to mention often making it impossible to >>>> undeploy them). > > Yes, but I would be very surprised if one could cause a different > webapp to service a request by doing such a thing. What you might be > able to do is get the request *logged* to the wrong webapp, if you > were fetching references (say, to the ServletContext) and caching them > in the (shared) class, then calling ServletContext.log on them. > > Aristedes, can you describe in a bit more detail the kinds of things > you are doing, here? > > Also, what kind of logging are you using that suggests your requests > are being handled by the wrong webapp? What does JMX have to say about > the number of active sessions? (You said that the 'manager' webapp > shows a status for the webapp, so you are probably using that session > count in your reports, here, but I just wanted to check). > > >> I'll focus on trying to get some better logging of the session into the >> log output and see if we can narrow down the symptoms. Yes, I am using >> JMX and the Manager app to identify when there are no remaining >> sessions, and when I therefore should expect to see no further activity >> at all from the older application. I'll try and get some better >> information around that by adding logging as you suggest. > >> The logging that we did originally to discover this problem was simple: > >> * sessionless application >> * we changed the log.properties for log4j in the new app >> * some hours after we deployed, the old-style log entries were still >> being written, mixed in with the new ones Aristedes, Did you manage to resolve the problem or narrow down on what is actually happening? p signature.asc Description: OpenPGP digital signature
Re: parallel deployment: multiple applications responding
On 28/02/12 12:14 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 2/26/12 11:29 PM, Caldarale, Charles R wrote: From: Aristedes Maniatis [mailto:amania...@apache.org] Subject: Re: parallel deployment: multiple applications responding What happens if our application defines a static class or other resource? Not sure what you mean by "static class", unless you're referring to an inner class. Regardless, each parallel deployment uses a separate classloader, so the webapp instances cannot interfere with each other. I'm sure he means a class with a static method that returns a shared object (aka singleton, etc.). Yes of course. I mispoke earlier. However, if you've placed classes in a shared library (e.g., Tomcat's lib directory), anything in there will be shared by all webapps. You must be very, very careful when utilizing shared classes, since that can easily lead to unexpected data leakage between webapps (not to mention often making it impossible to undeploy them). Yes, but I would be very surprised if one could cause a different webapp to service a request by doing such a thing. What you might be able to do is get the request *logged* to the wrong webapp, if you were fetching references (say, to the ServletContext) and caching them in the (shared) class, then calling ServletContext.log on them. Aristedes, can you describe in a bit more detail the kinds of things you are doing, here? Also, what kind of logging are you using that suggests your requests are being handled by the wrong webapp? What does JMX have to say about the number of active sessions? (You said that the 'manager' webapp shows a status for the webapp, so you are probably using that session count in your reports, here, but I just wanted to check). I'll focus on trying to get some better logging of the session into the log output and see if we can narrow down the symptoms. Yes, I am using JMX and the Manager app to identify when there are no remaining sessions, and when I therefore should expect to see no further activity at all from the older application. I'll try and get some better information around that by adding logging as you suggest. The logging that we did originally to discover this problem was simple: * sessionless application * we changed the log.properties for log4j in the new app * some hours after we deployed, the old-style log entries were still being written, mixed in with the new ones Thanks for your suggestions, I'll investigate a few more things and get better information. At least I know this isn't some simple newbie known issue. Cheers Ari - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9LgbUACgkQ9CaO5/Lv0PBYoACfSFRbddQN1BNkBT5Q4GzhP2zA o4MAnRZVmV0mhFOj7Wu94JX76nbV9DFB =ugoA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: parallel deployment: multiple applications responding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 2/26/12 11:29 PM, Caldarale, Charles R wrote: >> From: Aristedes Maniatis [mailto:amania...@apache.org] Subject: >> Re: parallel deployment: multiple applications responding > >> What happens if our application defines a static class or other >> resource? > > Not sure what you mean by "static class", unless you're referring > to an inner class. Regardless, each parallel deployment uses a > separate classloader, so the webapp instances cannot interfere > with each other. I'm sure he means a class with a static method that returns a shared object (aka singleton, etc.). > However, if you've placed classes in a shared library (e.g., > Tomcat's lib directory), anything in there will be shared by all > webapps. You must be very, very careful when utilizing shared > classes, since that can easily lead to unexpected data leakage > between webapps (not to mention often making it impossible to > undeploy them). Yes, but I would be very surprised if one could cause a different webapp to service a request by doing such a thing. What you might be able to do is get the request *logged* to the wrong webapp, if you were fetching references (say, to the ServletContext) and caching them in the (shared) class, then calling ServletContext.log on them. Aristedes, can you describe in a bit more detail the kinds of things you are doing, here? Also, what kind of logging are you using that suggests your requests are being handled by the wrong webapp? What does JMX have to say about the number of active sessions? (You said that the 'manager' webapp shows a status for the webapp, so you are probably using that session count in your reports, here, but I just wanted to check). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9LgbUACgkQ9CaO5/Lv0PBYoACfSFRbddQN1BNkBT5Q4GzhP2zA o4MAnRZVmV0mhFOj7Wu94JX76nbV9DFB =ugoA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: parallel deployment: multiple applications responding
> From: Aristedes Maniatis [mailto:amania...@apache.org] > Subject: Re: parallel deployment: multiple applications responding > What happens if our application defines a static class or > other resource? Not sure what you mean by "static class", unless you're referring to an inner class. Regardless, each parallel deployment uses a separate classloader, so the webapp instances cannot interfere with each other. However, if you've placed classes in a shared library (e.g., Tomcat's lib directory), anything in there will be shared by all webapps. You must be very, very careful when utilizing shared classes, since that can easily lead to unexpected data leakage between webapps (not to mention often making it impossible to undeploy them). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: parallel deployment: multiple applications responding
On 27/02/12 2:12 PM, Christopher Schultz wrote: It would be nice if it showed as "disabled" (to use the mod_jk terminology for an instance which is running but gets no new sessions). It's just a coincidence that no new sessions are being created -- because sessionless requests /should/ be sent to the new version. The old version simply isn't used any more... it's not actually in any different state than the new version. Now this is interesting. What happens if our application defines a static class or other resource? Would both the new and old code be simultaneously loaded in the same JVM at the same time? Is there some way we might have been able to create an object in memory which is causing the requests to be handled by the wrong application? We are doing a few tricky things with parsing incoming requests which isn't a standard Tapestry way of working. Tomcat doesn't show any memory leaks when we press that button in the Tomcat Manager, but perhaps there is something in our code which confuses the code from the old and new applications? Is that even possible? The feature request for the auto-shutdown issue is here: https://issues.apache.org/bugzilla/show_bug.cgi?id=52777 I took the liberty of taking your notes in this list into the task so that the ideas are not lost. Cheers Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: parallel deployment: multiple applications responding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aristedes, On 2/23/12 4:29 AM, Aristedes Maniatis wrote: > Given that we've definitely seen this happen with our sessionless > application, I'm not sure that will help us much. For our other > apps which have sessions, what happens if the incoming cookie > references a session which has expired? Will the connection be > simply handled by the new application? Yes. > Is there some chance that the old application then creates a new > valid session for that connection? I suppose there is some chance (there could be a bug) bu I suspect something else is going on. Is it possible that some component you aren't expecting is in fact creating a session that is otherwise unused? Adding the session id to the logger would certainly shed some light on that. > What we did do is add a version to our log4j logger so that we > could see which application was handling requests. We got quite a > mixture of requests to the older sessionless application. That's interesting. Please confirm that the requests do not have any session id associated with them. > Is there a task I can follow? I was unable to find one. If you'd like, you can file an enhancement request in Bugzilla. I wasn't able to find anything anything that already existed. https://issues.apache.org/bugzilla >>> We have been thinking about writing an external application to >>> poll using JMX and do this, but that's quite a bit of work. It >>> would be nicer if this happened inside tomcat itself. >> >> Agreed. Patches welcome. > > Sure. I understand, but I would not know where to begin with the > tomcat codebase. I haven't even tried to read the source at this > point. I assume we'd need to hook into some listener that detects > when sessions are terminated and tell when they reach zero. That is > maybe one line of code in the right place... or not :-) I haven't looked at the code closely enough to know if this would all work, but it seems reasonable that you could do the following: 1. Modify the parallel deployment code to register an MBean NotificationListener that filters for useful events (such as expiring session notifications on the outgoing webapp). 2. When the listener receives a notification, check the current state (e.g. session count=0; or, I suppose you could make this a part of your filter in step #1). If session count = 0, start a new thread that stops the outgoing webapp and de-registers the listener. Or. 1. Install a SessionEventListener that counts-down the sessions (you'll have to get the count from JMX, I suppose) until they equal 0, then starts a new thread that ... etc. Or. 1. Install a Timer thread that polls at intervals (1 minute?) to see if all the sessions are dead and then starts a thread ... etc. The first idea seems the cleanest, though Tomcat might not actually fire MBean events for things like session count changing. Again, I haven't checked the code myself, yet. >>> 3. Is there some resource we might be hanging onto which is >>> preventing the old application from properly stopping? >> >> Maybe. But that would be a separate issue. > > I am just looking for solutions within the particular stack that we > are using (tapestry/cayenne) to see if there was some reason why > tomcat wasn't fully letting go of the older application. If there are pending sessions, Tomcat shouldn't terminate that webapp. As previously mentioned, Tomcat will not (yet) auto-undeploy the old version when all sessions have terminated. >>> 4. Should the tomcat manager show the older apps as still >>> running or should they be shown as stopped? >> >> running. > > It would be nice if it showed as "disabled" (to use the mod_jk > terminology for an instance which is running but gets no new > sessions). It's just a coincidence that no new sessions are being created -- because sessionless requests /should/ be sent to the new version. The old version simply isn't used any more... it's not actually in any different state than the new version. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9K9JQACgkQ9CaO5/Lv0PAsDACgmH786rjCWgaQgCWy3L2HjoMp 0w4An12U6AuWEytXy2qzwAMWqsWG6vSQ =LeiA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: parallel deployment: multiple applications responding
On 23/02/12 7:24 PM, Mark Thomas wrote: On 23/02/2012 06:51, Aristedes Maniatis wrote: We've been using parallel deployment for some time now with tomcat 7.0.25. For the most part the parallel deployment is a really nice idea, particularly because we don't have sessions serialised and clustered across all running instances. However, we've had mysterious problems for some time now where fixes we've applied to the application don't seem to work. We added some logging and have confirmed that some requests are still being served by the OLD instances of the application which are still deployed in the tomcat container but have an older version and therefore should not be responding. We might have two apps like this (using a format of YYMMDD and a two digit sequence): enrol##12022203.war enrol##12021503.war We would expect that requests would be served from only the newer application, but we find that requests continue to be served from the old, even though all the sessions to the old application are long dead. Just to confirm things we have another application which does not use sessions at all. It also has the same problem: requests are being served by the wrong application. In Tomcat Manager, the old application is still marked as running, but we thought this is just how it appears in the UI. Clearly there is something not right here. 1. Is this a known issue? We'd need to understand the root cause to answer that. The short version is that requests will only be routed to the old version if a request includes a session ID that references it. I'd suggest adding the session cookie to your access log. Given that we've definitely seen this happen with our sessionless application, I'm not sure that will help us much. For our other apps which have sessions, what happens if the incoming cookie references a session which has expired? Will the connection be simply handled by the new application? Is there some chance that the old application then creates a new valid session for that connection? What we did do is add a version to our log4j logger so that we could see which application was handling requests. We got quite a mixture of requests to the older sessionless application. 2. Is there some way to get the old application to fully undeploy as soon as it has no live sessions? No. It is on the to do list. Is there a task I can follow? I was unable to find one. We have been thinking about writing an external application to poll using JMX and do this, but that's quite a bit of work. It would be nicer if this happened inside tomcat itself. Agreed. Patches welcome. Sure. I understand, but I would not know where to begin with the tomcat codebase. I haven't even tried to read the source at this point. I assume we'd need to hook into some listener that detects when sessions are terminated and tell when they reach zero. That is maybe one line of code in the right place... or not :-) 3. Is there some resource we might be hanging onto which is preventing the old application from properly stopping? Maybe. But that would be a separate issue. I am just looking for solutions within the particular stack that we are using (tapestry/cayenne) to see if there was some reason why tomcat wasn't fully letting go of the older application. 4. Should the tomcat manager show the older apps as still running or should they be shown as stopped? running. It would be nice if it showed as "disabled" (to use the mod_jk terminology for an instance which is running but gets no new sessions). But that doesn't really affect our underlying problem: it would just make it easier to understand what is happening. Thanks for your time. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: parallel deployment: multiple applications responding
On 23/02/2012 06:51, Aristedes Maniatis wrote: > We've been using parallel deployment for some time now with tomcat > 7.0.25. For the most part the parallel deployment is a really nice idea, > particularly because we don't have sessions serialised and clustered > across all running instances. > > However, we've had mysterious problems for some time now where fixes > we've applied to the application don't seem to work. We added some > logging and have confirmed that some requests are still being served by > the OLD instances of the application which are still deployed in the > tomcat container but have an older version and therefore should not be > responding. We might have two apps like this (using a format of YYMMDD > and a two digit sequence): > > enrol##12022203.war > enrol##12021503.war > > We would expect that requests would be served from only the newer > application, but we find that requests continue to be served from the > old, even though all the sessions to the old application are long dead. > > Just to confirm things we have another application which does not use > sessions at all. It also has the same problem: requests are being served > by the wrong application. > > > In Tomcat Manager, the old application is still marked as running, but > we thought this is just how it appears in the UI. Clearly there is > something not right here. > > > 1. Is this a known issue? We'd need to understand the root cause to answer that. The short version is that requests will only be routed to the old version if a request includes a session ID that references it. I'd suggest adding the session cookie to your access log. > 2. Is there some way to get the old application to fully undeploy as > soon as it has no live sessions? No. It is on the to do list. > We have been thinking about writing an > external application to poll using JMX and do this, but that's quite a > bit of work. It would be nicer if this happened inside tomcat itself. Agreed. Patches welcome. > 3. Is there some resource we might be hanging onto which is preventing > the old application from properly stopping? Maybe. But that would be a separate issue. > 4. Should the tomcat manager show the older apps as still running or > should they be shown as stopped? running. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
parallel deployment: multiple applications responding
We've been using parallel deployment for some time now with tomcat 7.0.25. For the most part the parallel deployment is a really nice idea, particularly because we don't have sessions serialised and clustered across all running instances. However, we've had mysterious problems for some time now where fixes we've applied to the application don't seem to work. We added some logging and have confirmed that some requests are still being served by the OLD instances of the application which are still deployed in the tomcat container but have an older version and therefore should not be responding. We might have two apps like this (using a format of YYMMDD and a two digit sequence): enrol##12022203.war enrol##12021503.war We would expect that requests would be served from only the newer application, but we find that requests continue to be served from the old, even though all the sessions to the old application are long dead. Just to confirm things we have another application which does not use sessions at all. It also has the same problem: requests are being served by the wrong application. In Tomcat Manager, the old application is still marked as running, but we thought this is just how it appears in the UI. Clearly there is something not right here. 1. Is this a known issue? 2. Is there some way to get the old application to fully undeploy as soon as it has no live sessions? We have been thinking about writing an external application to poll using JMX and do this, but that's quite a bit of work. It would be nicer if this happened inside tomcat itself. 3. Is there some resource we might be hanging onto which is preventing the old application from properly stopping? 4. Should the tomcat manager show the older apps as still running or should they be shown as stopped? Cheers Ari Maniatis -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer, On 9/7/2009 6:05 AM, Rainer Jung wrote: > The code of mod_jk (1.2.28) looks for a URL encoded session id (and uses > that one if it finds one) and otherwise it takes all cookie session ids > it can find in the order of Cookie headers in the request. > > It then uses all the session ids in this order and searches for a usable > worker (e.g. existing and not being in error or stopped) until it finds > one or runs out of session ids. Okay, so if you were foolish enough to have nested webapp paths, then you'd be okay as long as the worker names didn't conflict, right? That might mean you'd need different s in order to satisfy your nested-url-space requirement, but at least the behavior would be predictable. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqpMzoACgkQ9CaO5/Lv0PBGRwCgtuOqeUYtM5v6k0JTbcw55pY9 Wq0AnjhRVt9s4Easg+e42a9TL66uFGYC =Z8eI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
Hi Chris, On 04.09.2009 16:29, Christopher Schultz wrote: > Rainer, > > On 9/4/2009 12:52 AM, Rainer Jung wrote: >> On 03.09.2009 23:31, Christopher Schultz wrote: >>> Whenever a client browses to webapps found on / and /foo, the requests >>> to /foo will get TWO cookies, and confusion may occur (I'm not sure what >>> mod_jk will do in this situation... Rainer?). > >> Not sure either :( > >> Even if I looked at the code now, I wouldn't take it for granted, that >> the behaviour can't change. > > Agreed. I don't have a cluster handy to test, but it would be good to > know what mod_jk actually does in the case where multiple JSESSIONID > cookies exist and have different jvmRoute suffixes. > >> Actually I'm not even sure what the browser is supposed to send (the >> same cookie multiple times, or only the one with the longest path >> match). > > My experience was that /both/ cookies were sent (which makes sense, > since there's no prohibition against the same cookie name being used > more than one time when a different path is used). OK, I did some (very little) work: RFC 2109 and 2965 both state: If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. Ordering with respect to other attributes (e.g., Domain) is unspecified. (sections 4.3.4 resp. 3.3.4). The code of mod_jk (1.2.28) looks for a URL encoded session id (and uses that one if it finds one) and otherwise it takes all cookie session ids it can find in the order of Cookie headers in the request. It then uses all the session ids in this order and searches for a usable worker (e.g. existing and not being in error or stopped) until it finds one or runs out of session ids. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer, On 9/4/2009 12:52 AM, Rainer Jung wrote: > On 03.09.2009 23:31, Christopher Schultz wrote: >> Whenever a client browses to webapps found on / and /foo, the requests >> to /foo will get TWO cookies, and confusion may occur (I'm not sure what >> mod_jk will do in this situation... Rainer?). > > Not sure either :( > > Even if I looked at the code now, I wouldn't take it for granted, that > the behaviour can't change. Agreed. I don't have a cluster handy to test, but it would be good to know what mod_jk actually does in the case where multiple JSESSIONID cookies exist and have different jvmRoute suffixes. > Actually I'm not even sure what the browser is supposed to send (the > same cookie multiple times, or only the one with the longest path > match). My experience was that /both/ cookies were sent (which makes sense, since there's no prohibition against the same cookie name being used more than one time when a different path is used). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhJEcACgkQ9CaO5/Lv0PDpggCgv1aVrfTiq9MH1SF2Td4Ha3EP iY0AoLnXxKeQ6iKeermF2JbvCRjEGoaQ =I2jx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
On 03.09.2009 23:31, Christopher Schultz wrote: > Rainer, > > On 9/3/2009 4:36 AM, Rainer Jung wrote: >> No. > >> The stickyness doesn't magically track your clients. If the client sends >> a session information, and the session information contains a route tag >> (a suffix .nodeX, where nodeX is set by the jvmRoute attribute in >> server.xml), then mod_jk looks for a balancer member named nodeX. > >> When/How does the client send session information? Either as a cookie >> named JSESSIONID, or via URL encoding ...;jsessionid=nodeX > >> By default, application A with context name /myappA uses cookies and >> only sends cookies if the request goes to something in /myappA. So a >> request for application B with context /myappB doesn't include the >> cookie for A and the load balancer is free to distribute the request to >> any node. > > One caveat: if you have a ROOT context along with other non-ROOT > contexts, things can get tricky because you'll get cookies like: > > name=JSESSIONID, path=/, expires=..., value=... > name=JSESSIONID, path=/foo, expires=..., value=... > name=JSESSIONID, path=/bar, expires=..., value=... > > Whenever a client browses to webapps found on / and /foo, the requests > to /foo will get TWO cookies, and confusion may occur (I'm not sure what > mod_jk will do in this situation... Rainer?). Not sure either :( Even if I looked at the code now, I wouldn't take it for granted, that the behaviour can't change. Actually I'm not even sure what the browser is supposed to send (the same cookie multiple times, or only the one with the longest path match). > My advice is to avoid "nesting" webapp URL spaces. I accidentally did > this for years until I discovered the problem when adding > sessionid-passthrough to another webapp (where the session id couldn't > be validated before being passed-through) and everything went crazy. > When I separated the URL spaces, everything was fine. > > Hope that helps, > -chris Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer, On 9/3/2009 4:36 AM, Rainer Jung wrote: > No. > > The stickyness doesn't magically track your clients. If the client sends > a session information, and the session information contains a route tag > (a suffix .nodeX, where nodeX is set by the jvmRoute attribute in > server.xml), then mod_jk looks for a balancer member named nodeX. > > When/How does the client send session information? Either as a cookie > named JSESSIONID, or via URL encoding ...;jsessionid=nodeX > > By default, application A with context name /myappA uses cookies and > only sends cookies if the request goes to something in /myappA. So a > request for application B with context /myappB doesn't include the > cookie for A and the load balancer is free to distribute the request to > any node. One caveat: if you have a ROOT context along with other non-ROOT contexts, things can get tricky because you'll get cookies like: name=JSESSIONID, path=/, expires=..., value=... name=JSESSIONID, path=/foo, expires=..., value=... name=JSESSIONID, path=/bar, expires=..., value=... Whenever a client browses to webapps found on / and /foo, the requests to /foo will get TWO cookies, and confusion may occur (I'm not sure what mod_jk will do in this situation... Rainer?). My advice is to avoid "nesting" webapp URL spaces. I accidentally did this for years until I discovered the problem when adding sessionid-passthrough to another webapp (where the session id couldn't be validated before being passed-through) and everything went crazy. When I separated the URL spaces, everything was fine. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqgNaEACgkQ9CaO5/Lv0PC7nQCgtvFONQbvlmx7zrz+rmKaFVdI PcgAnjDcnYoWXNmsMW8bIE58tSnUBFuG =9T+N -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
On 02.09.2009 23:38, Jason Wright wrote: > I've an interesting situation with our application clusters. I am running > multiple applications for one of our websites. We don't share sessions > between the different servers; we use sticky sessions instead. Session > replication is difficult because of the large size of our users' sessions. > > We use applications A & B. I would like application A to run on servers 1 > and 2 and application B to run on servers 3 and 4. > > The user initially requests application A and receives a sticky session for > server 1. Later, the user requests application B. Since the sticky session > was set, server 1 is accessed, but application B is not found. If No. The stickyness doesn't magically track your clients. If the client sends a session information, and the session information contains a route tag (a suffix .nodeX, where nodeX is set by the jvmRoute attribute in server.xml), then mod_jk looks for a balancer member named nodeX. When/How does the client send session information? Either as a cookie named JSESSIONID, or via URL encoding ...;jsessionid=nodeX By default, application A with context name /myappA uses cookies and only sends cookies if the request goes to something in /myappA. So a request for application B with context /myappB doesn't include the cookie for A and the load balancer is free to distribute the request to any node. > sticky_session_force is set, then another server is tried; however, the No, see above. No session info, then stickyness is never applied. If there were session info, then the force switch would work in the opposite way, namely if set to false, it will allow failover. Default is false. > sticky session will still be set to server 1 and the application B may not > use the same server. > > I've thought of 3 possible ways to solve this problem with a preference to > the one I don't know how to do yet. Not sure what the (real) problem is, likely you want both apps to be reachable under the same server name. > The first (my preference) is to be able to use multiple sticky sessions, one > for each application. This might involve multiple copies of modjk loaded by > tomcat with multiple workers.properties files, or something like that. I > would have no idea of how to do this. Does anyone know how to do this? No, this works out of the box. I assume there is no relation between the two apps A and B. Configute two lb workers, like lbA and lbB. One has member node1 and node 2, the other node3 and node4. Set the jvmRoute in server.xml of the four nodes to these names respectively. Finally add a JkMount /myappA|/* lbA JkMount /myappB|/* lbB That should be all that's needed. When testing, check the session cookies in order to understand what's going on. There are lots of Firefox plugins to look at cookies comfortably, like e.g. FireCookie. FireBug is also nice. > The second way of solving this problem is to use multiple copies of Tomcat > bound to different IP addresses with different configuration files. This > solution would be seen as subdomains to the user. > > The third way of solving this problem is to use multiple copies of Tomcat > bound to different ports (same IP address) with different configuration > files. This solution would have the same domain, but different port numbers. > > > I'm pretty sure that the second and third solutions would work, but I'm not > sure about the first solution. I've searched extensively and haven't found > anyone with the same problem. Has anyone on this list been in this situation > or know the best way to solve this problem? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod jk - multiple applications, different server clusers, sticky sessions
Hello, I've an interesting situation with our application clusters. I am running multiple applications for one of our websites. We don't share sessions between the different servers; we use sticky sessions instead. Session replication is difficult because of the large size of our users' sessions. We use applications A & B. I would like application A to run on servers 1 and 2 and application B to run on servers 3 and 4. The user initially requests application A and receives a sticky session for server 1. Later, the user requests application B. Since the sticky session was set, server 1 is accessed, but application B is not found. If sticky_session_force is set, then another server is tried; however, the sticky session will still be set to server 1 and the application B may not use the same server. I've thought of 3 possible ways to solve this problem with a preference to the one I don't know how to do yet. The first (my preference) is to be able to use multiple sticky sessions, one for each application. This might involve multiple copies of modjk loaded by tomcat with multiple workers.properties files, or something like that. I would have no idea of how to do this. Does anyone know how to do this? The second way of solving this problem is to use multiple copies of Tomcat bound to different IP addresses with different configuration files. This solution would be seen as subdomains to the user. The third way of solving this problem is to use multiple copies of Tomcat bound to different ports (same IP address) with different configuration files. This solution would have the same domain, but different port numbers. I'm pretty sure that the second and third solutions would work, but I'm not sure about the first solution. I've searched extensively and haven't found anyone with the same problem. Has anyone on this list been in this situation or know the best way to solve this problem? Thanks in advance, Jason Wright -- Jason Wright TCN Systems Administrator jason.wri...@tcnbroadcasting.com Office (866) 745-1901 x123 Cell (801) 687-3260
Re: Multiple applications
André Warnier wrote: Peter Flynn wrote: Hassan Schroeder wrote: On Tue, Jun 23, 2009 at 7:37 AM, Peter Flynn wrote: I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I now need to add Lucene and eXist. Is it possible to run multiple applications like this on the same machine using the same Tomcat server? Hi. I believe that I may be about at the same level as yourself for such things - which is far below the level of the gurus you have been talking to so far - and therefore that my explanations that follow, whilst being maybe less accurate, may be more accessible. This is excellent and very helpful, thank you very much. I will digest this when I next get a slot. Yes, I also dislike running the RHEL repackaging, but in this case the system is maintained by the engineers on the basis that I do *not* add non-RHEL versions of things that are available in RHEL packages. Silly, but unavoidable. RHEL is hopelessly out of date in so many areas, and they have this compulsion to meddle which is very annoying. But in the case of Tomcat I have located all the bits and pieces, so it's not a major problem. ///Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple applications
Peter Flynn wrote: Hassan Schroeder wrote: On Tue, Jun 23, 2009 at 7:37 AM, Peter Flynn wrote: I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I now need to add Lucene and eXist. Is it possible to run multiple applications like this on the same machine using the same Tomcat server? Hi. I believe that I may be about at the same level as yourself for such things - which is far below the level of the gurus you have been talking to so far - and therefore that my explanations that follow, whilst being maybe less accurate, may be more accessible. And if you can read and understansd the previous paragraph, then you should not have trouble with the Tomcat on-line documnentation either. So I would suggest to start by reading this page, which outlines the basic principles of the deployment of web applications under Tomcat : http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html In order to not get an overdose, skip for now anything in that page that talks about the Tomcat Manager or the TCD. We won't need them, since we're going to do thimgs by hand, in the good old traditional way. So, read only up to and including the section "Deployment on Tomcat startup" for now. First, two caveats : 1) One hurdle you are facing, is that these explanations relate to the way in which Tomcat is installed /if you were using the standard Tomcat as downloaded from the Tomcat website/. This is not your situation, since you are using a "RHEL repackaged Tomcat". I have to tell you that this is viewed with some distaste by some of the gurus on this forum, the - justified - reason of which is that these packages install things in different places than the standard Tomcat, and this makes it more difficult to help you. 2) Another hurdle is that you also already have elements in your server.xml, which also frowned upon nowadays. It is frowned upon also for good reasons, as it makes moving things around dynamically more difficult : you have to restart the server each time you make a change to server.xml, which is not ideal. About this second hurdle, the documentation page in question indicates, in the section "A word on Contexts", the better places for such things. A standard Tomcat installation lays out the stuff more or less as follows : Top install directory (also know as CATALINA_HOME) - bin - conf - logs - webapps .. and others less important here Also, when you are running a single instance of Tomcat on a host, the symbol CATALINA_BASE is equivalent to CATALINA_HOME above. In a pre-packaged installation, some of those subdirectories may be located elsewhere, and a variety of links installed, to tie it all together. That's what sometimes makes it challenging. The crucial sub-directory here is "webapps". That is where a standard Tomcat looks for web applications. It looks there, because in your element in your server.xml, there is an attribute named "appBase", which usually says "webapps". "webapps", unless it is an absolute path, is taken relative to CATALINA_BASE. Thus, when anyone accesses your site using the URL http://hostname/xyz Tomcat is going to look under the "appBase" directory, for a sub-directory named "xyz", and try to find a web application there to serve the call. A special case is the sub-directory called ROOT. That is where Tomcat will look for the "default web application", in other words the one people are looking for when they enter the URL http://hostname/ This default application could have just been located directly under the "webapps" sub-directory, but that would have been confusing, since then Tomcat would not know if ".../webapps/xyz" is a separate application called "xyz", or if it is a sub-directory of the default application. Because one element has only one "appBase" attribute, and because this appBase attribute names one directory (in the standard case, CATALINA_BASE/webapps), and because under this webapps there can only be one ROOT sub-directory, it follows that one Tomcat Host can only have one "default application". So you must choose which one that will be, and that will be the one users will access when they use the URL "http://yourhost/";. All other applucations - in the same Host - will have to be accessed by a URL such as "http://hostname/appname";. If you configure multiple 's, then each can have its own "appBase", under which each can have its own ROOT, and thus its own default application. But let's get back to an application named "myapp", which would not be the default application. Normally thus, Tomcat expects to find all the stuff related to this application, in the following hierarchy : CATALINA_BASE/webapps/myapp --- / (I mean, directly under &q
Re: Multiple applications
Hassan Schroeder wrote:
On Tue, Jun 23, 2009 at 7:37 AM, Peter Flynn wrote:
I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I
now need to add Lucene and eXist. Is it possible to run multiple
applications like this on the same machine using the same Tomcat
server?
Yes.
I only get a short time per month to look at this stuff so my apologies
for not getting back sooner.
At the moment, all Cocoon pages get an extra "cocoon/" token
inserted in their URI, eg http://myhost.server.domain/cocoon/stuff.
I did look at just replacing ROOT in webapps but that seems a
little heavy-handed,
Renaming a directory (or war file) is "heavy-handed"???
I would have thought so -- with an outsider's eyes. One doesn't normally
want to mess with the default directory layout of installed software,
only add to it and edit configs. I don't know what the default ROOT
actually does.
and it would seem to defeat any chance of adding Lucene and eXist.
No it wouldn't.
Excellent, thanks.
Look at the examples that come with the standard distro. It should be
apparent that (and how) multiple webapps are supported.
...and Caldarale, Charles R wrote:
> Clearly you can - look how many independent webapps are deployed in
> the standard Tomcat download.
Unfortunately that is opaque to me. This is /var/lib/tomcat5 (under RHEL4):
drwxr-x--- 5 root tomcat 4096 Feb 27 2008 balancer
drwxr-xr-x 9 tomcat tomcat 4096 Apr 21 12:00 cocoon
drwxrwxr-x 21 root tomcat 4096 Apr 7 2008 jsp-examples
drwxrwxr-x 4 root tomcat 4096 Apr 7 2008 ROOT
drwxrwxr-x 4 root tomcat 4096 Apr 7 2008 servlets-examples
drwxrwxr-x 12 root tomcat 4096 Apr 7 2008 tomcat-docs
drwxrwxr-x 3 root tomcat 4096 Apr 7 2008 webdav
Apart from cocoon, which I added, I am not aware of what balancer is or
what I might want it for. I can see examples, and tomcat-docs, and I
know what webdav is (although I don't use it). But these look to me like
utilities that come with Tomcat, rather than "apps". No matter, if apps
they are, that's fine.
Caldarale, Charles R wrote:
Replacing ROOT with your desired default webapp for the domain is not
heavy-handed, it's expected.
Aha.
You can obviously only have one default webapp per ; other
webapps for the have to be explicitly named.
Yes, but where does this explicit naming take place? server.xml? web.xml?
I currently have a Host element type in server.xml naming the host
(which is a cname; this is all front-ended by Apache with a VH):
...
This is currently all working and http://publish.ucc.ie is correctly
bringing up my Cocoon pages.
[me]
Is there another way to get rid of the "cocoon/", because the
Cocoon pages will be the interface the user sees (but somehow
preserve an equivalent "lucene/" and "eXist/" because they won't be
seen much)?
Rename your Cocoon webapp to ROOT (remove the old ROOT first), and
> install your Lucene and eXist applications under whatever names you
> choose under the appBase directory.
Leave Lucene and eXist aside for the moment. I renamed ROOT to OLDROOT
and renamed the cocoon directory to ROOT. Restarted tomcat and apache.
But when I tried http://publish.ucc.ie I got a Tomcat 404
The requested resource (/cocoon) is not available.
Somewhere it's not looking in the right place. What other changes are
needed to make it pick up the app that is in the ROOT directory?
(I've renamed them all back the way they were for the moment.)
You likely only have one , and if you haven't changed the
> default appBase setting, it's the webapps directory.
Exactly.
> Your structure should look like this:
${CATALINA_BASE}
> webapps
> ROOT (containing your Cocoon webapp)
> lucene (containing your Lucene webapp)
> exist (containing your eXist webapp)
Yes, although lucene and exist aren't there yet, and there is the other
default stuff in webapps as shown in the listing above.)
The names are case-sensitive, so choose them carefully; they can be
> anything you choose, other than ROOT.
I'm still trying to get it to serve cocoon when I move the default ROOT
out of the way and rename the cocoon directory to ROOT, but there is
obviously some other key piece of information I am missing here.
David Smith wrote:
You can name your cocoon webapp ROOT and then add lucene and eXist
webapps. If lucene or eXist webapps exist, the request will go to
them. It'll only hit ROOT if those webapps aren't there or running.
This falls under the requirement of servlet containers to make the
longest match at each stage of the decision making process. When
choosing which webapp, the longest match is used and then again at
the servlet mapping level, the longest match takes it.
That makes sense, except
Re: Multiple applications
Peter Flynn wrote: > I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I > now need to add Lucene and eXist. Is it possible to run multiple > applications like this on the same machine using the same Tomcat server? > > Someone mentioned something about "another Tomcat instance" but I > don't know if this is required, and I can't find any documentation > about it. > > At the moment, all Cocoon pages get an extra "cocoon/" token inserted > in their URI, eg http://myhost.server.domain/cocoon/stuff. I did look > at just replacing ROOT in webapps but that seems a little > heavy-handed, and it would seem to defeat any chance of adding Lucene > and eXist. > > Is there another way to get rid of the "cocoon/", because the Cocoon > pages will be the interface the user sees (but somehow preserve an > equivalent "lucene/" and "eXist/" because they won't be seen much)? > > ///Peter > You can name your cocoon webapp ROOT and then add lucene and eXist webapps. If lucene or eXist webapps exist, the request will go to them. It'll only hit ROOT if those webapps aren't there or running. This falls under the requirement of servlet containers to make the longest match at each stage of the decision making process. When choosing which webapp, the longest match is used and then again at the servlet mapping level, the longest match takes it. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Multiple applications
> From: Peter Flynn [mailto:pfl...@ucc.ie]
> Subject: Multiple applications
>
> Is it possible to run multiple applications like this on
> the same machine using the same Tomcat server?
Clearly you can - look how many independent webapps are deployed in the
standard Tomcat download.
> I did look at just replacing ROOT in webapps but that seems
> a little heavy-handed, and it would seem to defeat any chance
> of adding Lucene and eXist.
Replacing ROOT with your desired default webapp for the domain is not
heavy-handed, it's expected. You can obviously only have one default webapp
per ; other webapps for the have to be explicitly named.
> Is there another way to get rid of the "cocoon/", because the Cocoon
> pages will be the interface the user sees (but somehow preserve an
> equivalent "lucene/" and "eXist/" because they won't be seen much)?
Rename your Cocoon webapp to ROOT (remove the old ROOT first), and install your
Lucene and eXist applications under whatever names you choose under the
appBase directory.
You likely only have one , and if you haven't changed the default appBase
setting, it's the webapps directory. Your structure should look like this:
${CATALINA_BASE}
webapps
ROOT (containing your Cocoon webapp)
lucene (containing your Lucene webapp)
exist (containing your eXist webapp)
The names are case-sensitive, so choose them carefully; they can be anything
you choose, other than ROOT.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
Re: Multiple applications
On Tue, Jun 23, 2009 at 7:37 AM, Peter Flynn wrote: > > I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I now need > to add Lucene and eXist. Is it possible to run multiple applications like > this on the same machine using the same Tomcat server? Yes. > At the moment, all Cocoon pages get an extra "cocoon/" token inserted in > their URI, eg http://myhost.server.domain/cocoon/stuff. I did look at just > replacing ROOT in webapps but that seems a little heavy-handed, Renaming a directory (or war file) is "heavy-handed"??? > and it would seem to defeat any chance of adding Lucene and eXist. No it wouldn't. Look at the examples that come with the standard distro. It should be apparent that (and how) multiple webapps are supported. -- Hassan Schroeder hassan.schroe...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multiple applications
I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I now need to add Lucene and eXist. Is it possible to run multiple applications like this on the same machine using the same Tomcat server? Someone mentioned something about "another Tomcat instance" but I don't know if this is required, and I can't find any documentation about it. At the moment, all Cocoon pages get an extra "cocoon/" token inserted in their URI, eg http://myhost.server.domain/cocoon/stuff. I did look at just replacing ROOT in webapps but that seems a little heavy-handed, and it would seem to defeat any chance of adding Lucene and eXist. Is there another way to get rid of the "cocoon/", because the Cocoon pages will be the interface the user sees (but somehow preserve an equivalent "lucene/" and "eXist/" because they won't be seen much)? ///Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
repost: looking for example using Mbean to for session management across multiple applications
Hi, (this is a repost. I inadvertently 'thread hijacked' when I initially posted this question). I'm looking for an example of using Mbeans to access the org.apache.catalina.Manager interface to manage HttpSessions. First off, however: is this possible? We're interested in using this approach for managing single signon between multiple web applications. (where accessing one session keeps alive other sessions). thanks, bill milbratz
Re: looking for example using Mbean to for session management across multiple applications
[EMAIL PROTECTED] wrote: > Hi, > > I'm looking for an example of using Mbeans to access the > org.apache.catalina.Manager interface to manage HttpSessions. When starting a new thread (ie sending a message to the list about a new topic) please do not reply to an existing message and change the subject line. To many of the list archiving services and mail clients used by list subscribers this makes your new message appear as part of the old thread. This makes it harder for other users to find relevant information when searching the lists. This is known as thread hijacking and is behaviour that is frowned upon on this list. Frequent offenders will be removed from the list. It should also be noted that many list subscribers automatically ignore any messages that hijack another thread. The correct procedure is to create a new message with a new subject. This will start a new thread. Mark tomcat-user-owner - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
looking for example using Mbean to for session management across multiple applications
Hi, I'm looking for an example of using Mbeans to access the org.apache.catalina.Manager interface to manage HttpSessions. First off, however: is this possible? We're interested in using this approach for managing single signon between multiple web applications. (where accessing one session keeps alive other sessions). thanks, bill milbratz - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Create an object that's shared with multiple applications?
You can serialize/deseriaize your object(s) in /from an Ms SQLserver blob field I can email you some code off list if this is what you are looking forward Phil -Original Message- From: 0 8 [mailto:[EMAIL PROTECTED] Sent: 09 August 2006 20:14 To: Tomcat Users List Subject: Re: Create an object that's shared with multiple applications? Pid, I'm sure this is a stupid question but...what? I don't follow. I can store the object in a database? I'm limited to SQL Server. Does that matter? On 8/9/06, Pid <[EMAIL PROTECTED]> wrote: > put it in a database? > > 0 8 wrote: > > Hello, > > > > I currently have a JSP application under Tomcat that uses an object > > created when Tomcat starts up. The object is created using a class > > that implements ServletContextListener and I can call the object > > from my JSPs. All is well. > > > > Originally, I thought I could have one of these objects per > > application. But it turns out I can have only one per server. > > > > I've been doing some searching and looking through the > > documentation, but I can't figure out how to do this. > > > > How can I create a single object when Tomcat starts up and access > > that object from multiple web apps? > > > > Thanks, > > Matt > > > > > > - To start a new topic, e-mail: users@tomcat.apache.org To > > unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, > e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.8/414 - Release Date: 09/08/2006 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create an object that's shared with multiple applications?
Pid, I'm sure this is a stupid question but...what? I don't follow. I can store the object in a database? I'm limited to SQL Server. Does that matter? On 8/9/06, Pid <[EMAIL PROTECTED]> wrote: put it in a database? 0 8 wrote: > Hello, > > I currently have a JSP application under Tomcat that uses an object > created when Tomcat starts up. The object is created using a class > that implements ServletContextListener and I can call the object from > my JSPs. All is well. > > Originally, I thought I could have one of these objects per > application. But it turns out I can have only one per server. > > I've been doing some searching and looking through the documentation, > but I can't figure out how to do this. > > How can I create a single object when Tomcat starts up and access that > object from multiple web apps? > > Thanks, > Matt > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create an object that's shared with multiple applications?
I did, but then I get more than I get one object created for each application. I literally just stumbled a mention of a "crossContext" setting in Tomcat, but I'm still trying to figure out if that will help here. On 8/9/06, Ryan O'Hara <[EMAIL PROTECTED]> wrote: > How can I create a single object when Tomcat starts up and access that > object from multiple web apps? > > Thanks, > Matt Have you added listener and listener-class tags in each applications' web.xml? Ryan - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create an object that's shared with multiple applications?
How can I create a single object when Tomcat starts up and access that object from multiple web apps? Thanks, Matt Have you added listener and listener-class tags in each applications' web.xml? Ryan - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create an object that's shared with multiple applications?
check jndi ressources On 8/9/06, Pid <[EMAIL PROTECTED]> wrote: put it in a database? 0 8 wrote: > Hello, > > I currently have a JSP application under Tomcat that uses an object > created when Tomcat starts up. The object is created using a class > that implements ServletContextListener and I can call the object from > my JSPs. All is well. > > Originally, I thought I could have one of these objects per > application. But it turns out I can have only one per server. > > I've been doing some searching and looking through the documentation, > but I can't figure out how to do this. > > How can I create a single object when Tomcat starts up and access that > object from multiple web apps? > > Thanks, > Matt > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create an object that's shared with multiple applications?
put it in a database? 0 8 wrote: > Hello, > > I currently have a JSP application under Tomcat that uses an object > created when Tomcat starts up. The object is created using a class > that implements ServletContextListener and I can call the object from > my JSPs. All is well. > > Originally, I thought I could have one of these objects per > application. But it turns out I can have only one per server. > > I've been doing some searching and looking through the documentation, > but I can't figure out how to do this. > > How can I create a single object when Tomcat starts up and access that > object from multiple web apps? > > Thanks, > Matt > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Create an object that's shared with multiple applications?
Hello, I currently have a JSP application under Tomcat that uses an object created when Tomcat starts up. The object is created using a class that implements ServletContextListener and I can call the object from my JSPs. All is well. Originally, I thought I could have one of these objects per application. But it turns out I can have only one per server. I've been doing some searching and looking through the documentation, but I can't figure out how to do this. How can I create a single object when Tomcat starts up and access that object from multiple web apps? Thanks, Matt - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
