Tomcat 7 Parallel Deployment Issues

215 views
Skip to first unread message

Tristan Emerson

unread,
Jan 21, 2014, 12:36:23 PM1/21/14
to memcached-se...@googlegroups.com
I'm using Tomcat 7.0.47 and memcached-session-manager on CentOS 6.4, and I've been able to make everything work fine except for parallel deployment.  When two versions of a project are deployed (e.g. /FOO##001 and /FOO##002) to a Tomcat instance running MSM the request always returns a HTTP 400 code.  Unfortunately nothing is written to the log files when this happens, so there's no stack trace to analyze.

I tried updating to Tomcat 7.0.50, and while setting everything up I noticed that parallel deployment works fine until the context.xml file is changed to include the <Manager> tag with all of the MSM configuration.

I noticed a Stack Overflow post pointing out the same issue, but it wasn't really resolved.  This also has already been brought up in this group, but the details provided may have been too sparse to go on.  I can provide any additional details; I didn't include any log files because nothing is logged when this happens.

Martin Grotzke

unread,
Jan 21, 2014, 2:01:00 PM1/21/14
to memcached-session-manager

AFAICS parallel deployment needs to be explicitly supported by msm in that way, that msm respects the webapp/context version when storing a session in memcached. So it's somehow related to https://code.google.com/p/memcached-session-manager/issues/detail?id=173.

For now, can you turn on debug logging as described in SetupAndConfiguration?

Out of interest: are you running only a single tomcat? Why do you want to use both msm and parallel deployment? If you have more than one tomcat you should be able to deploy (stop/deploy/start) one after the other (msm supports this as "tomcat failover"). If you have only one tomcat, why are you using msm?

Cheers,
Martin

--
 
---
You received this message because you are subscribed to the Google Groups "memcached-session-manager" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memcached-session-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Tristan Emerson

unread,
Jan 21, 2014, 3:50:55 PM1/21/14
to memcached-se...@googlegroups.com, martin....@googlemail.com
We are running multiple Tomcats.  I do have failover configured, but we're having some unrelated serialization issues in third party libraries, which means failover is less than perfectly seamless.  Parallel deployment also gives us the option to roll back to a previous version easily, so if nothing else it makes me feel all warm and fuzzy inside.

I did enable FINE logging.  Is there anything specific you're looking for?  I see lots of "checking session" statements (see below), but I don't see anything being logged when Tomcat is returning the 400 error.

Jan 21, 2014 2:48:46 PM de.javakaffee.web.msm.MemcachedSessionService updateExpirationInMemcached
FINE: Checking session 3B80ED1F9211B01911EF05115CFBEBCA-n1.node3:
- isValid: true
- isExpiring: false
- isBackupRunning: false
- isExpirationUpdateRunning: false
- wasAccessedSinceLastBackup: false
- memcachedExpirationTime: -26
To unsubscribe from this group and stop receiving emails from it, send an email to memcached-session-manager+unsub...@googlegroups.com.

Martin Grotzke

unread,
Jan 21, 2014, 6:12:21 PM1/21/14
to memcached-session-manager
On 01/21/2014 09:50 PM, Tristan Emerson wrote:
> We are running multiple Tomcats. I do have failover configured, but
> we're having some unrelated serialization issues in third party
> libraries, which means failover is less than perfectly seamless.
> Parallel deployment also gives us the option to roll back to a previous
> version easily, so if nothing else it makes me feel all warm and fuzzy
> inside.

Ok, I understand.


> I did enable FINE logging. Is there anything specific you're looking
> for? I see lots of "checking session" statements (see below), but I
> don't see anything being logged when Tomcat is returning the 400 error.

Ok then. I just started working on a solution for this but I need to get
back to my business, perhaps I have s.th. working the next days.

Cheers,
Martin


>
> Jan 21, 2014 2:48:46 PM de.javakaffee.web.msm.MemcachedSessionService
> updateExpirationInMemcached
> FINE: Checking session 3B80ED1F9211B01911EF05115CFBEBCA-n1.node3:
> - isValid: true
> - isExpiring: false
> - isBackupRunning: false
> - isExpirationUpdateRunning: false
> - wasAccessedSinceLastBackup: false
> - memcachedExpirationTime: -26
>
>
>
> On Tuesday, January 21, 2014 2:01:00 PM UTC-5, Martin Grotzke wrote:
>
> AFAICS parallel deployment needs to be explicitly supported by msm
> in that way, that msm respects the webapp/context version when
> storing a session in memcached. So it's somehow related to
> https://code.google.com/p/memcached-session-manager/issues/detail?id=173
> <https://code.google.com/p/memcached-session-manager/issues/detail?id=173>.
>
> For now, can you turn on debug logging as described in
> SetupAndConfiguration?
>
> Out of interest: are you running only a single tomcat? Why do you
> want to use both msm and parallel deployment? If you have more than
> one tomcat you should be able to deploy (stop/deploy/start) one
> after the other (msm supports this as "tomcat failover"). If you
> have only one tomcat, why are you using msm?
>
> Cheers,
> Martin
>
> Am 21.01.2014 18:55 schrieb "Tristan Emerson" <tristan...@gmail.com
> <javascript:>>:
>
> I'm using Tomcat 7.0.47 and memcached-session-manager on CentOS
> 6.4, and I've been able to make everything work fine except for
> parallel deployment
> <http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment>.
> When two versions of a project are deployed (e.g. /FOO##001 and
> /FOO##002) to a Tomcat instance running MSM the request always
> returns a HTTP 400 code. Unfortunately nothing is written to
> the log files when this happens, so there's no stack trace to
> analyze.
>
> I tried updating to Tomcat 7.0.50, and while setting everything
> up I noticed that parallel deployment works fine until the
> context.xml file is changed to include the <Manager> tag with
> all of the MSM configuration.
>
> I noticed a Stack Overflow post pointing out the same issue
> <http://stackoverflow.com/questions/15957528/simple-method-of-session-migration-between-parallel-tomcat-webapps>,
> but it wasn't really resolved. This also has already been
> brought up
> <https://groups.google.com/forum/#!topic/memcached-session-manager/VLW8TPZZ8HI>
> in this group, but the details provided may have been too sparse
> to go on. I can provide any additional details; I didn't
> include any log files because nothing is logged when this happens.
>
> --
>
> ---
> You received this message because you are subscribed to the
> Google Groups "memcached-session-manager" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> memcached-session-...@googlegroups.com
> <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>

--
inoio gmbh - http://inoio.de
Schulterblatt 36, 20357 Hamburg
Amtsgericht Hamburg, HRB 123031
Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn

signature.asc

Martin Grotzke

unread,
Jan 23, 2014, 8:31:21 PM1/23/14
to memcached-session-manager

I just added a build/jars of msm that includes a fix for issue 173
https://code.google.com/p/memcached-session-manager/issues/detail?id=173

With this you can configure storageKeyPrefix="webappVersion" for msm.
Does this solve the issue?

Cheers,
Martin

Tristan Emerson

unread,
Jan 24, 2014, 8:15:44 AM1/24/14
to memcached-se...@googlegroups.com, martin....@googlemail.com
That seems to have fixed it!  Thanks so much for getting to this so quickly, all your work on this project is greatly appreciated.

Paul Jones

unread,
May 25, 2017, 5:23:39 PM5/25/17
to memcached-session-manager, martin....@googlemail.com
Hi Martin,

Sorry for bringing up an old thread. I am pulling my hair out with this a the moment.

I have a single tomcat server which we do parallel deployments to. So the users aren't logged off the app with an invalid session and they just carry on being served by the old version until they log out.

so wars look like app##1.war app##2.war etc

I have now clustered a couple of tomcats and am using memcached to share the sessions across both servers.

The thing i can't get working is seamlessly deploying a new war to both servers and not logging the users off.

I have tried the storage key set to webappVersion but this hasn't helped.

Would you be able to help?

Is what I am trying to achieve possible?

Thanks 

>         <javascript:>.
>         For more options, visit https://groups.google.com/groups/opt_out
>         <https://groups.google.com/groups/opt_out>.
>

--
inoio gmbh - http://inoio.de
Schulterblatt 36, 20357 Hamburg
Amtsgericht Hamburg, HRB 123031
Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn



Join us in looking after the environment - only print this email if absolutely necessary.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This communication may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. 

Applied Relational Technology Ltd. Company No. 1589528, Registered Office:  The Old Rectory, Ashford Road, Canterbury, Kent, CT4 7HS.

Martin Grotzke

unread,
May 25, 2017, 5:44:07 PM5/25/17
to Paul Jones, memcached-session-manager

Hi Paul,

can you activate debug logging and share logs?

Cheers,
Martin



>         <javascript:>.
>         For more options, visit https://groups.google.com/groups/opt_out
>         <https://groups.google.com/groups/opt_out>.
>

--
inoio gmbh - http://inoio.de
Schulterblatt 36, 20357 Hamburg
Amtsgericht Hamburg, HRB 123031
Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn

Reply all
Reply to author
Forward
0 new messages