-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeffrey,
On 7/23/13 5:51 PM, Jeffrey Janner wrote: >> -----Original Message----- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Monday, July 22, 2013 >> 5:45 PM To: Tomcat Users List Subject: Re:[OT] Enable session >> persistence between two tomcat nodes behind load balancer >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Jeffrey, >> >> On 7/22/13 10:00 AM, Jeffrey Janner wrote: >>>> -----Original Message----- From: vi...@thepenguin.org >>>> [mailto:vi...@thepenguin.org] Sent: Saturday, July 20, 2013 >>>> 7:25 AM To: Tomcat Users List Subject: Enable session >>>> persistence between >> two >>>> tomcat nodes behind load balancer >>>> >>>> Hello: >>>> >>>> I have been searching for an answer to how to set this up. I >>>> find a lot of posts on session persistence but none seem to >>>> describe how to set it up. Is there a simple explanation out >>>> there that tells me how I go about setting up session >>>> persistence (with Apache, I would just set up memcached on >>>> the db server and configure the memcache module on each >>>> Apache instance to point to the memcached and it works). I >>>> don't need opcode persistence. I just want the tomcats to >>>> either a) direct all session traffic to a single node or b) >>>> make the two tomcats aware of all sessions. Can someone point >>>> me in the right direction? I am not a java coder, but if code >>>> changes need to be made, I can work through it. >>>> >>>> Thanks, >>>> >>>> Vicki >>>> >>>> >>> >>> Vicki - I think you've got your terms a little mixed up here, >>> but not much. From your description what you are really looking >>> for is >> session >>> "replication". You are in luck, because the default server.xml >>> has a commented out section on how to set up replication right >>> there (at least up to Tomcat 6.x). You also want to review the >>> documentation on replication on the Tomcat website for your >>> release (http://tomcat.apache.org). I said "not much" above, >>> because replication relies on persistence-ability, meaning they >>> both need the same basic setup in order to work. As I recall >>> from looking into it (but not setting up a production setup), >>> you must declare your sessions persistable in your code for >>> either function to work properly. Jeff p.s. In case you're >>> wondering why not production, >> turns >>> out our initial dev team put way too much info in the session >>> to make replication a feasible option for us at the time. I >>> think we've been whittling it away over time, but haven't tried >>> it since the first effort. >> >> I've written (but not actually used - it was just a >> proof-of-concept) a Filter and HttpSession wrapper that can wrap >> session data in an object wrapper whose only member is a >> transient Object reference[1]. This will allow you to throw >> "huge" objects into the session that won't be sent across the >> wire (only their empty wrappers will be sent). >> >> If your application will tolerate a session attribute "suddenly" >> being null, and can recover from that by re-building the >> necessary data, you could use the same trick to enable Tomcat's >> session persistence. >> >> - -chris >> >> [1] You can also do something similar with WeakReference objects, >> which allows you to keep huge amounts of data cached in your >> sessions but allow the garbage collector to discard some of that >> cached data if it's getting low on memory. > > Thanks for the insight Chris, but I seriously doubt our code is > that resilient. Besides, I'd much rather have code that's done > "right" rather than a bunch of band-aids to work around the > issues. Honestly, I consider this to be a valid technique for caching rather than just a band-aid. But the underlying code has to be tolerant, of course. > Having a similar discussion right now about an issue that could be > fixed in under 10 lines of code changes, a rebuild, and an update > of the affected client (a phoneapp), but I'm have to deal with it > in a massive configuration change because that's "easier" for the > dev team. (Codespeack for "no one really knows how to modify > phoneapp"). Hah... the justification is probably that the "code has already been tested" and configuration changes don't require re-testing. Introduce them to the concept of automated/unit testing :) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR7+tLAAoJEBzwKT+lPKRYe8kQAMMOKRhHck6wjeNFzC+S64b7 GVo7VlEnCBAS+IoKbsOMsU3yb09D6Y90j3C6A7Mik7bpe7Qwg197D4+3N2stR7Rj NkDHOk43gXe53rsxIo63ZPXFkW+zI++1vA4do3GLj5hYz+MdhzKJmMcUHf5i8fEK PD7mvsWwk7MOrQdZSgRUOYbaRsO6MKPyOOJOiCYZ/6o8Ug7n0jInZXvq0X2w9qf9 Kg6p7daggoKiBrFjcRng+cIyfKa4mYFqZSrk/Y+bbBar1ny20XSvqRO5bnuFq08W hEfJQwDMI4h0z9GkCAHSoXk/e3sM1RUN5VQlqG7LQ8OInxZ5PPIsq1QmrL9hhaux 5UkrvhNYl5pljqVXec6pWMvqWq6t56xZBGEfwTosoKq5ZBFbqKUiNf/qeo4Z87x+ 7K20JEgNrRpBUeoLUEoxb26JSq18vwHNdoUqjibnOJsWgUJIlM7z1PCC6SI5FCQd xx8c9bnfZjeV8D5u4eEgYjr08G7mW9lc08j5IjbagEcxOg9U24RRHgSaNn12PnJv 0Vkuo1GkLXXx/iYpFH2fQEMu5Q0ebasGawnSu+Kln/eB1wlpgPU5I0wZ3HecN8G1 8fD2wpYZvlJQdRl6hFvkKMcu4zLLb+9TkmrlrtYC4Lj8TF+IoSjG1eiIzaDvGACE aWNEgEFU5GBAQewIv0Ce =Oyym -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
