deployment question/issue

[GoogleCodeExporter]

What is the best practice for deploying a webapp using 
memcached-session-manager onto multiple servers when sticky-sessions are used?  
 If I understand the documentation correctly the context.xml for each server 
would be slightly different with respect to how the memcached nodes are 
referenced.   That means creatinga  different WAR file for each server, which 
is brittle from an integration/deployment standpoint.

My first strategy was to try and put the context.xml outside of the app so it 
would be specific to the server.   So I tried putting the context.xml into 
~catalina/conf/Catalina/localhost.  However, I found that Tomcat deletes that 
folder each time the webapp is redeployed or replaced with a new version. 

Original issue reported on code.google.com by st...@regattacentral.com on 5 Feb 2014 at 9:42

[GoogleCodeExporter]

Did you read this?  
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context:
Individual Context elements may be explicitly defined: In individual files 
(with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ 
directory. The context path and version will be derived from the base name of 
the file (the file name less the .xml extension). This file will always take 
precedence over any context.xml file packaged in the web application's META-INF 
directory.

Does this work for you?

Original comment by martin.grotzke on 6 Feb 2014 at 12:29

[GoogleCodeExporter]

I did try that.  however, the file gets deleted by Tomcat when the application 
is unloaded prior to the update to the new version of the war.  I tried with 
both Tomcat Manager and LiveRebel (LiveRebel just does an unload of the old 
version and load of the new version and transfers requests to the other node 
during that downtime)

is it ok to put these settings in the ~catalina/conf/context.xml instead? If 
so, which jars would get put in ~catalina/lib instead of the WEB-INF/lib and 
would they need to go in both places?  

The goal is to be able to deploy the same war file on all nodes for each 
application and have each app pick up the correct memcached settings for that 
server.
Thanks

Original comment by st...@regattacentral.com on 6 Feb 2014 at 1:00

[GoogleCodeExporter]

 I did try that.  however, the file gets deleted by Tomcat when the application is unloaded prior to the update to the new version of the war.

Hmm, I'd need to try this myself, unfortunately my time is currently very 
limited to analyze this. You could ask the tomcat-users list - that's the right 
place for this question.

 Is it ok to put these settings in the ~catalina/conf/context.xml instead?

Yes.

 If so, which jars would get put in ~catalina/lib instead of the WEB-INF/lib and would they need to go in both places?

Location of jars is independent from the tomcat config, just follow the 
SetupAndDocumentation.

Original comment by martin.grotzke on 6 Feb 2014 at 8:21

[GoogleCodeExporter]

I tried putting the Manager setting into ~catalina/conf/context.xml.   However 
that generates exceptions for any of the apps which don't have the necessary 
serialization jars in their own ~WEB-INF/lib (e.g. the default /manager app is 
an example).  

Is it ok to put the serialization jars (e.g.kryo) into ~catalina/lib or could 
there class-loader issues or side effects?  

My goal is to ensure apps such as /manager will still run without modification 
while also ensuring that our app will use the Memcache manager with the Manager 
node settings saved externally of the war file. 

Thanks!
Steve

Here is the exception I get.  

Caused by: java.lang.ClassNotFoundException: 
de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:270)

Original comment by st...@regattacentral.com on 6 Feb 2014 at 9:10

[GoogleCodeExporter]

 Is it ok to put the serialization jars (e.g.kryo) into ~catalina/lib or could there class-loader issues or side effects?

This will cause classloader issues because then kryo cannot access classes from 
your application (from WEB-INF/{classes,lib}).

So you should solve your issue with the deleted 
$CATALINA_BASE/conf/[enginename]/[hostname]/ directory and put your context 
configuration there.
Btw, I just unpacked a fresh apache-tomcat-7.0.50, deployed a sample.war, 
copied the context.xml from webapps/sample/META-INF/context.xml to 
$CATALINA_BASE/conf/Catalina/localhost/sample.xml, modified it, redeployed 
sample.war and still had my modified sample.xml. Working as expected.

Original comment by martin.grotzke on 6 Feb 2014 at 10:36

[GoogleCodeExporter]

Thank you Martin. I will try 7.0.50.  Perhaps they have changed the newer 
version so it doesn't delete the xml file in ~/conf/Catalina/localhost.

Please note that this isn't so much a modification and then reload as an unload 
of the old war and a load of a new unpacked war (via the LiveRebel app 
management control center UI).

My fallback plan is to just reference is to just have the same settings in both 
context.xml and one of the two servers will end up using the other server as 
the primary rather than localhost. Not quite as efficient but at least I won't 
have to create different war files or modify settings after uploading a new war.

thx,
Steve

Original comment by st...@regattacentral.com on 6 Feb 2014 at 10:47

[GoogleCodeExporter]

Btw, did you try using system variables, e.g. set 
`JAVA_OPTS=-Dmsm.failoverNodes="n1"` and then in your context.xml use this via 
`failoverNodes="${msm.failoverNodes}"`?

Original comment by martin.grotzke on 6 Feb 2014 at 10:57