Re: persisting sessions best practices
Thank you to Dan and Chris for your valuable comments. On 1/19/15 9:21 AM, Daniel Mikusa wrote: Question 1: Is the documentation still correct after all these years of BackupManager being used? Is it still considered of lower reliability? It's just saying that less people use it. Because DeltaManager is the default and works fine in a lot of cases, the majority of users are just going to stick with it. Naturally then less people use BackupManager. It's not implying that BackupManager has problems. I've see BackupManager used a bunch of times and it worked great every time. Great. Then just as a summary, let me outline the options: Choice 1: to stick or not to stick If you use sticky sessions, then any session persistence layer is just there as a backup in case of failure of that node. So, for example, memcache would be used almost entirely to write entries and is never read from. If you don't use sticky sessions, then the session persistence layer becomes a new point of failure and needs its own redundancy and load balancing. Choices 2: which backend * JDBC * memcache * backup manager (can only be used in sticky mode) * delta manager For my needs I think the backupManager is the way to go. No extra moving parts, very simple to implement and not too much extra network traffic. On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz wrote: My question would be whether you are engineering to solve a problem that does not yet exist. We went through this conversation years ago at $work, and decided that users having to re-authenticate in the event of a failure was an okay compromise given all the work it would require to keep a high-availability cluster up and running. Our user's needs simply aren't that critical. This is actually designed to make our life easier with sysadmin more than anything. We can then take an instance offline to adjust memory usage, attach a profiler or anything else, without worrying about doing it out of hours or slowly waiting for all sessions to expire. If you have commit rights to the tomcat documentation, can I suggest that you add your notes about HttpSession.setAttribute(). That hint is absolutely invaluable! Thanks Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 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
persisting sessions best practices
I have some applications currently using sticky sessions in tomcat 7. Everything works well except that restarting tomcat requires disabling mod_jk new sessions to an instance, waiting for sessions to expire and then several hours later restarting the instance. This process is slow and not resilient to unexpected failures. So I want to persist sessions and allow session failure in the cluster. It appears that I have several approaches: * JDBC * memcache [1] * DeltaManager * BackupManager I discounted JDBC quite quickly because I don't want to add any load to my existing database. DeltaManager seems simple, but I'm weary of sending lots of data to all the nodes in my cluster (there are 12) which aren't even running the application. So BackupManager seems better for my needs. However the documentation [2] suggests that BackupManager may not be as reliable. Question 1: Is the documentation still correct after all these years of BackupManager being used? Is it still considered of lower reliability? My next decision is between memcache and BackupManager/DeltaManager. memcache will require another service to be running, so slightly more maintenance and one more thing to fail. However memcache seems to be very commonly used and I'm not sure why. Are there benefits it will bring to this arrangement (such as visibility of live sessions in some sort of GUI) or something else I'm not seeing. Question 2: Are there advantages to running memcache as a session store? I'll be continuing to use sticky sessions since I think that will be more reliable (the system will survive the failure of the session store/replication, whatever I choose). Thanks for any advice Ari [1] https://code.google.com/p/memcached-session-manager/ [2] http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 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: fronting tomcat with reverse proxy+SSL
What problem are you trying to solve by doing this? It seems to serve little purpose. Decrypt the traffic from the browser using Apache httpd, then re-encrypt the data and pass it onto tomcat. Why? I am sure it will work fine, but your performance will depend on the traffic you have. No one can answer that question for you. Ari On 28/05/12 3:35pm, al so wrote: It would be nice if I can hear from someone who has done such familiar setup. Have you seen any performance issues in setting up SSL both at Tomcat and Apache? Do you use same keys/certs at both Tomcat and Apache? On Sun, May 27, 2012 at 11:43 AM, al so volks...@gmail.com wrote: I've used standalone Tomcat to serve as web server+SSL+web container in the past. Now, I am trying to front Tomcat with apache reverse proxy+SSL. 1. Is it not redundant to configure the SSL in the Tomcat as well when the fronting reverse proxy is already configured to handle SSL. I see lot of posts on the internet which configure SSL at both Tomcat and Reverse proxy. Am I missing something? -- -- Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A -- -- 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 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
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
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
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
path to application in parallel deployment
I have another parallel deployment question: I am deploying Solr within a
custom war application and it requires a path to its config files. Before
parallel deployment I had this entry in context.xml:
Environment name=solr/home value=${ROOTDIR}/app/A1/webapps/search-internal/WEB-INF/classes/solr
type=java.lang.String override=false/
But now, I cannot predict the name of the application path (since it looks like this
search-internal##11081701). I have also been unsucessful in putting this
environment entry inside the application itself and using a relative path, since it
appears to be relative to tomcat and not to the application.
Is there some magic like a ${APP_ROOT} variable I can use?
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: path to application in parallel deployment
On 25/08/11 12:15 AM, Christopher Schultz wrote: So, if you could do this with code it would be: getServletContext().getRealPath(/WEB-INF/classes/solr) Right? Yes. There isn't any system property for this kind of thing (since system properties are JVM-wide, and not specific to any particular webapp) so it would have to be, as you say, some kind of magic variable that you could use. Are all properties JVM-wide? If I define a property in: webapps/someapp##1234/META-INF/context.xml Then that property is available to all applications? I didn't know that. If that's the case, then this approach will never work. I don't believe such a variable exists. Since Solr is servlet context-aware application (i.e. it *is* webapp), is it possible to give it a path relative to the webapp itself? You might want to ask the Solr folks about this. Sure. I can try there next, but any such solution is going to involve changing Solr code. Another option, which I think is a better option, would be to locate solr/home outside of your deployment directory. That is an option, but a very awkward one since then I have an application separated from the configuration which is an integral part of its functionality. This isn't some JDBC connection which differs in every deployment, but the configuration of exactly how the application works. So being able to keep it in our SCM with the code and deploy together is essential. Thanks 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: path to application in parallel deployment
On 25/08/11 12:43 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aristedes,
On 8/24/2011 10:36 AM, Aristedes Maniatis wrote:
On 25/08/11 12:15 AM, Christopher Schultz wrote:
So, if you could do this with code it would be:
getServletContext().getRealPath(/WEB-INF/classes/solr)
Right?
Yes.
Okay... glad I understand the goal :)
There isn't any system property for this kind of thing (since
system properties are JVM-wide, and not specific to any
particular webapp) so it would have to be, as you say, some kind
of magic variable that you could use.
Are all properties JVM-wide?
All system properties (retrieved using System.getProperty()) are
JVM-global.
If I define a property in:
webapps/someapp##1234/META-INF/context.xml
Those aren't system properties -- they /will/ be local to the webapp.
Right, then theoretically at least, there could be a ${APP_ROOT} which could be
available in there so that paths within the application could be addressed. I
guess this use case is rare since code within the application is usually able
to find resources on the classpath within the application.
I don't believe such a variable exists. Since Solr is servlet
context-aware application (i.e. it *is* webapp), is it possible
to give it a path relative to the webapp itself? You might want
to ask the Solr folks about this.
Sure. I can try there next, but any such solution is going to
involve changing Solr code.
Maybe not. Most webapp configurations assume that paths are relative
to the webapp itself.
Our testing so far seems to suggest that it is relative to the tomcat install.
But I'll follow this up with the Solr people. Thanks for the pointer.
Another option, which I think is a better option, would be to
locate solr/home outside of your deployment directory.
That is an option, but a very awkward one since then I have an
application separated from the configuration which is an integral
part of its functionality.
What goes in solr/home, anyway? I figured that the indexes go in
there, not just a configuration file or two.
It contains files such as the schema definition (which is similar to a database
schema definition, only for Lucene), instructions on how to parse data sources,
weightings for query facets, etc. The actual index can be in a different path.
This isn't some JDBC connection which differs in every deployment,
but the configuration of exactly how the application works. So
being able to keep it in our SCM with the code and deploy together
is essential.
Fair enough. I think the Solr list is the place to go. Definitely let
us know what the answer is.
Thanks again
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
Parallel deployment and session replication
I am an enthusiastic user of the new parallel deployment feature of tomcat 7. But I'm a little unclear about how it interacts with session replication. If I have a cluster of tomcat instances: instance1/A#001.war instance2/A#001.war instance3/A#001.war And they are all replicating sessions (say using SimpleTcpCluster). Then I want to upgrade, so I introduce more war files: instance1/A#001.war instance1/A#002.war instance2/A#001.war instance2/A#002.war instance3/A#001.war instance3/A#002.war Now, since these are effectively the same applications, they are all on the same multicast address and port. So I assume that sessions will now replicate between all 6 instances. * Will the old instances ever shut down? That is, will the sessions ever die on the old instances if they are part of the session replication cluster? * Is parallel deployment only designed to work with sticky sessions? Thanks 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
