Re: persisting sessions best practices
On Tue, Jan 27, 2015 at 3:03 AM, Aristedes Maniatis a...@ish.com.au wrote: 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. You've got the gist of it. Sticky sessions get you 90% of the way there. If that's good enough for your usage, you can stop there. If you can't afford to lose a session then you've got to go the remaining 10% and setup clustering or shared storage for the session data. 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. Correct. Tomcat's Clustering support works in a peer to peer fashion, so data is replicated between the Tomcat nodes. If you use a session store, session data is persisted to that store. The store itself could be a single node or multiple nodes in an HA configuration. That's up to you though. Dan 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
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
Re: persisting sessions best practices
On Sun, Jan 18, 2015 at 9:27 PM, Aristedes Maniatis a...@ish.com.au wrote: 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. I would agree. You don't want DeltaManager with that many cluster nodes. This is just my opinion but I wouldn't go over three or four nodes with DeltaManager. So BackupManager seems better for my needs. However the documentation [2] suggests that BackupManager may not be as reliable. Agree, BackupManager seems like it'll fit your needs better. Do you mean this comment? Downside of the BackupManager: not quite as battle tested as the delta manager. 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. 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. I've not personally used memcache, but I have used redis, so I guess that's a similar approach. The technology was a nice fit, but it didn't seem like a huge win versus the out-of-the-box session replication. Both worked and both were fast enough for what I needed. I stuck with the out-of-the-box stuff because it's distributed and replicated by default and didn't require an extra server. Where I've mainly used redis is in restricted environments where direct communication from one node to the other is not possible, like in some cloud environments, or when it's not as easy to setup like when multicast is disabled. Dan 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: [OT] persisting sessions best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 1/19/15 9:21 AM, Daniel Mikusa wrote: I've not personally used memcache, but I have used redis, so I guess that's a similar approach. Are you using Redis for session persistence? The technology was a nice fit, but it didn't seem like a huge win versus the out-of-the-box session replication. Both worked and both were fast enough for what I needed. I stuck with the out-of-the-box stuff because it's distributed and replicated by default and didn't require an extra server. Aah, so you evaluated it and discarded it as an option for sessions because it didn't offer much over what comes with Tomcat? Where I've mainly used redis is in restricted environments where direct communication from one node to the other is not possible, like in some cloud environments, or when it's not as easy to setup like when multicast is disabled. I'm curious because I looked at a handful of packages for this kind of thing (we are storing authentication nonces that need to be accessible from all of our Tomcat servers) and we settled on memcached if only for its simplicity and solid reputation. Some things it cannot do: 1. Replicate to other nodes. You can do sharding, but it's pretty low-brow and the shards don't actually know about each other. All of the smarts are in the client. The server doesn't do any of this. Evidently, there are some flavors of memcached that have been hacked to provide replication to other nodes, but it's not part of the main distribution and didn't seem ... safe. 2. Dump its database to disk. If you restart, you lose everything. 3. Allow you to browse. Basically, if you know an item's key, you can fetch its value. If you don't, you are out of luck. You can't just poke around looking for things. There is no equivalent of SELECT * LIMIT 5 just to see what's in there. Does Redis do any of the above? Honestly, I think what Tomcat needs is a session manager for Cassandra or something similar: something intended to be a primary data store and not a cache (like memcached is). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvStFAAoJEBzwKT+lPKRYXP8P/iQknECivamRE2+XPH9KSnzh BMwnq1TudZ20qFZbwnxA33Yli4DwEM6Sug7mph+R3iDVgqkR5srMfNeGUciwwFN7 4IUObktVQxg21VbSachilfi2Aat33FYTlmtHf+plDQAr0ig41pOKhujuF6pWWM3V RNJZQgmAivQXgA86RavIaVX+7x4HeB+w8iTYQm6dGbCpTWIADeqBuT358dTKRX+D Ricvs1M7C37LJNCyymKSgKlxAf7MF39viW9lHBsMp45o166vWcAGjj6juNuXDyBD xdk6UbkqbGIQ+No1W20BQZEm7mL8cCq8NYqs6YHwf9rV3v6rP4E0CTH1ubNN4q/K AwWtT5ijP7xA3cPxXEs7XdL6ynsMMJublk2/+V/+ctPE2XP7kfQCMBYhPSiux1Kc ILikydk5u0X0Dudmes4r9g6+wabnR9OC6/lB3c6BRG6kOdbj+VJo+23vbUQZkAHt lCVjjTirrvb6YLXuv+IXUomAlLn7bzQ39M1L1UO5wsRUd2kICnpZ7G5Cs3n5r98B WWSBLvChvez/hnt2HP3PlTBstW06R1Ds9FvkSMtVoO3roQSPEx6b1QCEsnw1NXCL SvAgN43FzXZxOyr+ZohGzUhSELXQI5v7pV6p3Bj+tMrAL/+fzMiS4KoJqDWc7/nB 3NlP1g/7RN1IYnLkFm+q =Po13 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: persisting sessions best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aristedes, On 1/18/15 9:27 PM, Aristedes Maniatis wrote: 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. If users losing sessions is tolerable, then fail-over will certainly work in unexpected failure situations. 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. You can certainly set up a separate database just for session persistence if you'd like. 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. DeltaManager doesn't scale well beyond a certain number of nodes unless you are using multicast. I'm not sure what that magic number is... it probably is different in every environment. So BackupManager seems better for my needs. However the documentation [2] suggests that BackupManager may not be as reliable. BackupManager trades speed for safety: you lose some safety but gain a lot of speed. Question 1: Is the documentation still correct after all these years of BackupManager being used? Is it still considered of lower reliability? See above. It's only less reliable because of the design. No, that hasn't changed. 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. memcached isn't magic: it's just a key/value store and it's pretty reliable. However: memcached is *not* meant to be a primary data store. Instead, its meant to be a cache with a real primary store behind it. When you restart your memcached service, it generally flushes the cache (that is, it forgets everything). That being said, we use it in production as a primary data store for some data that's okay to lose if the service goes down. It's not for user session data, but similar: if we lose all the data, some users might be inconvenienced, but we don't lose any data that needs to exist long-term. In our usage scenario, memcached has never failed (/me knocks wood). 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). If you use memcached for your sessions, the session data will be persisted to memcached whenever it is changed. If you are using sticky sessions (a good idea in general IMO) along with that, then you can probably assume that the current node is always the source of session data, so you never have to go back into memcached to freshen the session unless you are experiencing a fail-over event. In that case, you fetch the session data from memcached on the new node (the one that took-over for the failed one) and update the session id (the base id will stay the same, I believe, but the node identifier added to the end will change -- like 2389423412.node1 - 2389423412.node2), and then the new node becomes the source node. So, unless failover is actively occurring, you will only write to memcached when session data actually changes. Note that most of these live session-persistence schemes require that you call HttpSession.setAttribute() on each attribute you want to update in the backing-store. This isn't something that most people do as a matter of course. So for example, this code: HttpSession session = request.getSession(true); WorkflowState ws = session.getAttribute(workflow_state); ws.setState(WorkflowState.COMPLETED); // end of code ...will have to change if you want the new workflow state to be pushed back to the backing store. It's easy, you just have to remember to add this to your code: session.setAttribute(workflow_state, ws); 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. So I'd advise you to have a frank conversation amongst your team to decide if this is something you really want to do.
Re: [OT] persisting sessions best practices
On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 1/19/15 9:21 AM, Daniel Mikusa wrote: I've not personally used memcache, but I have used redis, so I guess that's a similar approach. Are you using Redis for session persistence? Yes, but I have used it for other things. It's a good project. The technology was a nice fit, but it didn't seem like a huge win versus the out-of-the-box session replication. Both worked and both were fast enough for what I needed. I stuck with the out-of-the-box stuff because it's distributed and replicated by default and didn't require an extra server. Aah, so you evaluated it and discarded it as an option for sessions because it didn't offer much over what comes with Tomcat? Basically. I was curious and tried it out. It worked fine, although I can't say I tested it exhaustively. Main reasons I stuck with clustering support in Tomcat are a.) it's all include with Tomcat, no additional JAR's or code needed b.) I'm very familiar with it's configuration troubleshooting c.) no additional server needed and d.) session data is automatically distributed across multiple nodes with Tomcat, for Redis I'd have to set that up or live with it being a single point of failure. Where I've mainly used redis is in restricted environments where direct communication from one node to the other is not possible, like in some cloud environments, or when it's not as easy to setup like when multicast is disabled. I'm curious because I looked at a handful of packages for this kind of thing (we are storing authentication nonces that need to be accessible from all of our Tomcat servers) and we settled on memcached if only for its simplicity and solid reputation. Some things it cannot do: 1. Replicate to other nodes. You can do sharding, but it's pretty low-brow and the shards don't actually know about each other. All of the smarts are in the client. The server doesn't do any of this. Evidently, there are some flavors of memcached that have been hacked to provide replication to other nodes, but it's not part of the main distribution and didn't seem ... safe. I believe the situation with Redis is similar. There some ways to do this with the stable 2.x release, but those have their are drawbacks. There's official clustering support in 3.0, which is still beta, though. It's supposed to resolve these issues. 2. Dump its database to disk. If you restart, you lose everything. You can save state with Redis. It's pretty flexible about how you configure it too, giving you different trade-offs between durability and performance. 3. Allow you to browse. Basically, if you know an item's key, you can fetch its value. If you don't, you are out of luck. You can't just poke around looking for things. There is no equivalent of SELECT * LIMIT 5 just to see what's in there. I think you'd be looking for the KEYS command. http://redis.io/commands/keys This is off topic, but it's really why I like Redis so I'm going to share. With Redis, not only can a key point to a value, but it can also point to other data structures like sets, lists, hashes and sorted sets. Something I've found to be very handy. Dan Does Redis do any of the above? Honestly, I think what Tomcat needs is a session manager for Cassandra or something similar: something intended to be a primary data store and not a cache (like memcached is). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvStFAAoJEBzwKT+lPKRYXP8P/iQknECivamRE2+XPH9KSnzh BMwnq1TudZ20qFZbwnxA33Yli4DwEM6Sug7mph+R3iDVgqkR5srMfNeGUciwwFN7 4IUObktVQxg21VbSachilfi2Aat33FYTlmtHf+plDQAr0ig41pOKhujuF6pWWM3V RNJZQgmAivQXgA86RavIaVX+7x4HeB+w8iTYQm6dGbCpTWIADeqBuT358dTKRX+D Ricvs1M7C37LJNCyymKSgKlxAf7MF39viW9lHBsMp45o166vWcAGjj6juNuXDyBD xdk6UbkqbGIQ+No1W20BQZEm7mL8cCq8NYqs6YHwf9rV3v6rP4E0CTH1ubNN4q/K AwWtT5ijP7xA3cPxXEs7XdL6ynsMMJublk2/+V/+ctPE2XP7kfQCMBYhPSiux1Kc ILikydk5u0X0Dudmes4r9g6+wabnR9OC6/lB3c6BRG6kOdbj+VJo+23vbUQZkAHt lCVjjTirrvb6YLXuv+IXUomAlLn7bzQ39M1L1UO5wsRUd2kICnpZ7G5Cs3n5r98B WWSBLvChvez/hnt2HP3PlTBstW06R1Ds9FvkSMtVoO3roQSPEx6b1QCEsnw1NXCL SvAgN43FzXZxOyr+ZohGzUhSELXQI5v7pV6p3Bj+tMrAL/+fzMiS4KoJqDWc7/nB 3NlP1g/7RN1IYnLkFm+q =Po13 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] persisting sessions best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 1/19/15 11:46 AM, Daniel Mikusa wrote: On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz ch...@christopherschultz.net wrote: Some things [memcached] cannot do: 1. Replicate to other nodes. You can do sharding, but it's pretty low-brow and the shards don't actually know about each other. All of the smarts are in the client. The server doesn't do any of this. Evidently, there are some flavors of memcached that have been hacked to provide replication to other nodes, but it's not part of the main distribution and didn't seem ... safe. I believe the situation with Redis is similar. There some ways to do this with the stable 2.x release, but those have their are drawbacks. There's official clustering support in 3.0, which is still beta, though. It's supposed to resolve these issues. Interesting. I also considered Voldemort, but honestly I was looking for something that was likely to be higher-performing than a Java hash map :) (/This/ from a Java programmer!) 2. Dump its database to disk. If you restart, you lose everything. You can save state with Redis. It's pretty flexible about how you configure it too, giving you different trade-offs between durability and performance. Cool. 3. Allow you to browse. Basically, if you know an item's key, you can fetch its value. If you don't, you are out of luck. You can't just poke around looking for things. There is no equivalent of SELECT * LIMIT 5 just to see what's in there. I think you'd be looking for the KEYS command. Yeah, memcached does not have that. There are ways to hack-out some keys but there is no command to list anything. http://redis.io/commands/keys This is off topic, but it's really why I like Redis so I'm going to share. With Redis, not only can a key point to a value, but it can also point to other data structures like sets, lists, hashes and sorted sets. Something I've found to be very handy. Well, in memcached values are binary, so you can stuff anything you want in there. You can serialize a whole object tree if that's what you want to do. I can imagine that memcached + JSON is a popular combination. We just put plain-old binary values in as keys at this point, but assuming you can serialize to bytes (like always!), you can store anything you want in memcached. But it's not like a formal column-store like Cassandra, etc. where the storage mechanism understands a bit about the structures being stored. It's basically an implementation of Mapbyte[],byte[] and we treat it like it's Mapbyte[],Integer because we are not really even using the values themselves; just the keys for quick lookup. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUvVnRAAoJEBzwKT+lPKRYi9wQAJJ6rYClvss+i4/sGGaCQQXZ MJbVpI7tkcIaz/PFOcK7o5yJXl5F+trdMnfkIM2VGV21fvbRBe28u1c6EeA8yd8P mmuXeLjZnOSPmKngR6LgtxSC8/IAba18DeuiDBkQ/Jgw207BXBZul8ELzm1H0ihF B8GtWv5BgvASIl7r+8MX793rfBc2qDmyfV5f56EhyodZKPuBQ+nYBwZZWoNOZN38 NxC3bs9U5+MCimVPqU8CF11m+gJXaV/sK1wqrDFJP0watHHyLJ7kHpN35RU4TeSF mYTYbQUxPKPaIZ+dPeo2yJZJadHZ4K3IX3vC9cgIz5sayTTl6esTMclzYCGMrFBI BRj9EywYCSWdgo7ZG6p3lZPjmXSe/oEEAt00YolpnR/jyjkyzMT/k+GoS4+1n81A QmV0U95i3i+D6E2RCR9YGa2O1yFhk5H9BuTYq+E831vrVP+XICP6vugICYdy5KUv IPghVDlYoUuKSe7KDDNKvKnoLKC755OHg18spjlBRsTESVm1Ht1+yscaAtlbEwWB TeZDfLsezIns6rp/9/qt6vB9g1zTZSNvepYB3cNKBabhj7lMd0K6Zdu4bvEpxLOO dnrEXFzByG8vQ0mi/NAWcBBZJfcDMo4IHngqi3MDFUITHukxOg1TKa2238Rxi6If 3o5leMJ4BUfBBhnfKGn0 =JnfC -END PGP SIGNATURE- - 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
