Re: JDBCStore
Am 23.10.2014 um 19:45 schrieb spr...@gmx.eu: You may want to have a look at parallel deployment ( http://tomcat.apache.org/tomcat-7.0-doc/config/context.html). At the moment /Catalina/localhost/ is used as value in column app. It is the root app. Would a war ROOT##2.war use another value? No. OK, then this would not solve the prob. Sorry, the name used for the app column changes with the version number. So you can use it. Felix Thx! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore
You may want to have a look at parallel deployment ( http://tomcat.apache.org/tomcat-7.0-doc/config/context.html). At the moment /Catalina/localhost/ is used as value in column app. It is the root app. Would a war ROOT##2.war use another value? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore
Are you using distributed sessions? If so, you'll have to override the internal serialization mechanism and do it all manually in a way that is going to be cross-version-compatible. It's not impossible, but it does take some planning and forethought. OK; thought so. Thank you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore
Am 23. Oktober 2014 13:34:22 MESZ, schrieb spr...@gmx.eu: You may want to have a look at parallel deployment ( http://tomcat.apache.org/tomcat-7.0-doc/config/context.html). At the moment /Catalina/localhost/ is used as value in column app. It is the root app. Would a war ROOT##2.war use another value? No. Felix - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore
You may want to have a look at parallel deployment ( http://tomcat.apache.org/tomcat-7.0-doc/config/context.html). At the moment /Catalina/localhost/ is used as value in column app. It is the root app. Would a war ROOT##2.war use another value? No. OK, then this would not solve the prob. Thx! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBCStore
Am 23.10.2014 um 19:45 schrieb spr...@gmx.eu: You may want to have a look at parallel deployment ( http://tomcat.apache.org/tomcat-7.0-doc/config/context.html). At the moment /Catalina/localhost/ is used as value in column app. It is the root app. Would a war ROOT##2.war use another value? No. OK, then this would not solve the prob. Well, I think it solves your problem. Old session-ids will get routed to the old version of your webapp and thus will be deserialized without a problem. New sessions will be created in the new version. This will enable a smooth transition from your old version to the new one. Regards Felix Thx! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore
Well, I think it solves your problem. Old session-ids will get routed to the old version of your webapp and thus will be deserialized without a problem. New sessions will be created in the new version. Yes, but the session persistence will go into the same table rows - chrash while deserialization. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBCStore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 10/22/14 3:20 PM, spr...@gmx.eu wrote: when I deploy a new app version with incompatible serialization version of same classes I get: java.io.InvalidClassException: org.hibernate.collection.internal.AbstractPersistentCollection; local class incompatible: stream classdesc serialVersionUID = -8914173462748164853, local class serialVersionUID = -7238232378593030571, at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:615), at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1620), at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515), at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1620), at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515), at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769), at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348), at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989), at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913), at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796), at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348), at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989), at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913), at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796), at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348), at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989), at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913), at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796), at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348), at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989), at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913), at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796), at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348), at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370), at org.apache.catalina.session.StandardSession.readObject(StandardSession.java: 1595), at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.j ava:1060), at org.apache.catalina.session.JDBCStore.load(JDBCStore.java:657), at org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:159), at Is there something in Tomcat to configure that can solve this problem? No. You will have to change your code to make it serialization-compatible with the old code if you don't want to have this problem. You can configure Tomcat not to serialize sessions, but then you obviously don't get the benefit of persisting sessions across a restart. If not, how to handle such a problem? Especially in clusters where servers get updated one by one and not all at once. Are you using distributed sessions? If so, you'll have to override the internal serialization mechanism and do it all manually in a way that is going to be cross-version-compatible. It's not impossible, but it does take some planning and forethought. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUSDKhAAoJEBzwKT+lPKRYiSsP/3SBlNzlA86+FU4c6KqsDhcv 5FdM/pkaKd2gQPf+m2PQMDG/LhOzfJUW8S65xTlg2YfTRFx7XBB4O0xHm7SZBH0B /Z0jSsbFHruZDesvdE+NM/5C4c2DjiC90ndk6YK3kHy1CCZQsDWuSGfoXe50IR6u MrCV842trrs0PpBngjbFh4Ha0UDuk8ZpRmw0dJ4V4a3Cta7jNZO3cQY0/vPqhNs+ hJ8GcEYpnqnltSrlwI3Eht5ckuZenarLiHl2o16sV2XL/VLoDwWN2+bajXkT6bb2 DOqMBys3fWUnu5icnCccbtT36GjSPsMqpwPfEStxb5arJzNYi1rz+B3OX8RTAFrX 01QOqz8zMo0tYS6UkCyVFIQ5mSTQjH0ewgnaOyQjfvakvSkbfjF9XFb8p1PH4LXN bmO2K4VaOBCu2FQtwsVe+8l9tjvMLTqHniBlm9U7f9ows/JoZqrt1riXtVuXXgOI QC9gZK4/Xsp9sVpbplc+FLTbsllCUxe/lIsGYV6xEeKHvZroO58cEN3swebYsosm ro4k9mXK1NwaG8l6byd1R2PzBg/0o49+NpLegCnEX7mf634ZuVFiMApmSZxbW6jE G+EJmFaGiTTziOqqaTCT40ZfyttbCSE2Oox0mkUOUVPtzUUkL1B72UXeq9X4Bc9i vuIMhP0bVHwMtPkiCMMh =XjD+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBCStore
Am 22. Oktober 2014 21:20:12 MESZ, schrieb spr...@gmx.eu: Hi, when I deploy a new app version with incompatible serialization version of same classes I get: java.io.InvalidClassException: org.hibernate.collection.internal.AbstractPersistentCollection; local ... Is there something in Tomcat to configure that can solve this problem? You may want to have a look at parallel deployment ( http://tomcat.apache.org/tomcat-7.0-doc/config/context.html). Regards Felix If not, how to handle such a problem? Especially in clusters where servers get updated one by one and not all at once. Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBCStore Persistent Manager
I had the same requirement and tried everything possible with the Persistent Manager. I use the Memcached Session Manager (non-sticky approach) and it works brilliantly. Take a look at this which may be of help to you : http://www.reinwaldwarapen.com/2011/01/storing-and-sharing-sessions-among.html On 4/26/2011 6:54 PM, Martin Grotzke wrote: An option for such a case is memcached-session-manager with stickyness disabled: http://code.google.com/p/memcached-session-manager/ A user reported on the msm mailing list that he was trying to achieve the same what you want, also with persistentmanager, but ran into the same problem as you do. This is the thread on the msm list: http://groups.google.com/group/memcached-session-manager/browse_thread/thread/fd26a2e407c080b4 Cheers, Martin Am 26.04.2011 13:48 schrieb Badh, Tajvindertajvinder.b...@emc.com: Hi, We have an architecture such that we have 2 instances of Apache Tomcat 6 sitting under the Amazon ELB. We are having difficulties in session stickyness over HTTPS such that that requests are not being directed to the same Tomcat instance, therefore creating a new session when the request is directed to a different instance. One possible solution was to use the Tomcat JDBCStore Persistent Mananger so that session information is held centrally in a database. This did not seem to work as intended as the minimum time to write session details to the database was 10 seconds. This clearly did not solve the problem as the users interaction with the application would be less than 10 seconds. I am wating to know if there is a way to speed up the write process? I have used the FileStore and this also has the same problems. Can someone please advise in how to get this to work? The configuration in context.xml I am using is : Manager className=org.apache.catalina.session.PersistentManager distributable=true checkInterval=1 saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=0 maxIdleBackup=0 Store className=org.apache.catalina.session.JDBCStore connectionURL=connection url driverName=com.mysql.jdbc.Driver connectionName=name connectionPassword=password sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=sessions sessionValidCol=valid_session/ /Manager Thanks, Taj - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore Persistent Manager
Hi, Thank you for the suggestions. I will take try it out and let you know how it goes. Regards, Taj -Original Message- From: Reinwald Warapen [mailto:reinwal...@directi.com] Sent: 27 April 2011 10:18 To: Tomcat Users List Cc: Badh, Tajvinder Subject: Re: JDBCStore Persistent Manager I had the same requirement and tried everything possible with the Persistent Manager. I use the Memcached Session Manager (non-sticky approach) and it works brilliantly. Take a look at this which may be of help to you : http://www.reinwaldwarapen.com/2011/01/storing-and-sharing-sessions-among.html On 4/26/2011 6:54 PM, Martin Grotzke wrote: An option for such a case is memcached-session-manager with stickyness disabled: http://code.google.com/p/memcached-session-manager/ A user reported on the msm mailing list that he was trying to achieve the same what you want, also with persistentmanager, but ran into the same problem as you do. This is the thread on the msm list: http://groups.google.com/group/memcached-session-manager/browse_thread /thread/fd26a2e407c080b4 Cheers, Martin Am 26.04.2011 13:48 schrieb Badh, Tajvindertajvinder.b...@emc.com: Hi, We have an architecture such that we have 2 instances of Apache Tomcat 6 sitting under the Amazon ELB. We are having difficulties in session stickyness over HTTPS such that that requests are not being directed to the same Tomcat instance, therefore creating a new session when the request is directed to a different instance. One possible solution was to use the Tomcat JDBCStore Persistent Mananger so that session information is held centrally in a database. This did not seem to work as intended as the minimum time to write session details to the database was 10 seconds. This clearly did not solve the problem as the users interaction with the application would be less than 10 seconds. I am wating to know if there is a way to speed up the write process? I have used the FileStore and this also has the same problems. Can someone please advise in how to get this to work? The configuration in context.xml I am using is : Manager className=org.apache.catalina.session.PersistentManager distributable=true checkInterval=1 saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=0 maxIdleBackup=0 Store className=org.apache.catalina.session.JDBCStore connectionURL=connection url driverName=com.mysql.jdbc.Driver connectionName=name connectionPassword=password sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=sessions sessionValidCol=valid_session/ /Manager Thanks, Taj - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JDBCStore Persistent Manager
Hi, I am looking at the configuration settings needed in context.xml for Memcached and am unsure as to what to enter in the memcachedNodes setting. Access to one of the Tomcat instances is : https://ec2-46-51-148-192.eu-west-1.compute.amazonaws.com:8443 Can you please help in defining what would need to be entered into this section of the configuration? Regards, Taj -Original Message- From: Badh, Tajvinder [mailto:tajvinder.b...@emc.com] Sent: 27 April 2011 11:19 To: Reinwald Warapen; Tomcat Users List Subject: RE: JDBCStore Persistent Manager Hi, Thank you for the suggestions. I will take try it out and let you know how it goes. Regards, Taj -Original Message- From: Reinwald Warapen [mailto:reinwal...@directi.com] Sent: 27 April 2011 10:18 To: Tomcat Users List Cc: Badh, Tajvinder Subject: Re: JDBCStore Persistent Manager I had the same requirement and tried everything possible with the Persistent Manager. I use the Memcached Session Manager (non-sticky approach) and it works brilliantly. Take a look at this which may be of help to you : http://www.reinwaldwarapen.com/2011/01/storing-and-sharing-sessions-among.html On 4/26/2011 6:54 PM, Martin Grotzke wrote: An option for such a case is memcached-session-manager with stickyness disabled: http://code.google.com/p/memcached-session-manager/ A user reported on the msm mailing list that he was trying to achieve the same what you want, also with persistentmanager, but ran into the same problem as you do. This is the thread on the msm list: http://groups.google.com/group/memcached-session-manager/browse_thread /thread/fd26a2e407c080b4 Cheers, Martin Am 26.04.2011 13:48 schrieb Badh, Tajvindertajvinder.b...@emc.com: Hi, We have an architecture such that we have 2 instances of Apache Tomcat 6 sitting under the Amazon ELB. We are having difficulties in session stickyness over HTTPS such that that requests are not being directed to the same Tomcat instance, therefore creating a new session when the request is directed to a different instance. One possible solution was to use the Tomcat JDBCStore Persistent Mananger so that session information is held centrally in a database. This did not seem to work as intended as the minimum time to write session details to the database was 10 seconds. This clearly did not solve the problem as the users interaction with the application would be less than 10 seconds. I am wating to know if there is a way to speed up the write process? I have used the FileStore and this also has the same problems. Can someone please advise in how to get this to work? The configuration in context.xml I am using is : Manager className=org.apache.catalina.session.PersistentManager distributable=true checkInterval=1 saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=0 maxIdleBackup=0 Store className=org.apache.catalina.session.JDBCStore connectionURL=connection url driverName=com.mysql.jdbc.Driver connectionName=name connectionPassword=password sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=sessions sessionValidCol=valid_session/ /Manager Thanks, Taj - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBCStore Persistent Manager
Hi Taj, say you have two tomcat servers that you can access at https://ec2-46-51-148-192.eu-west-1.compute.amazonaws.com:8443 and https://ec2-47-51-148-192.eu-west-1.compute.amazonaws.com:8443 and on both machines you have installed memcached, running on port 11211, then you can configure msm in both tomcat2 with memcachedNodes=n1:ec2-46-51-148-192.eu-west-1.compute.amazonaws.com:11211,n2:ec2-47-51-148-192.eu-west-1.compute.amazonaws.com:11211 For further questions regarding msm I suggest you ask on the msm mailing list (http://groups.google.com/group/memcached-session-manager/) as this is more specific to msm than to tomcat. Cheers, Martin On 04/27/2011 12:57 PM, Badh, Tajvinder wrote: Hi, I am looking at the configuration settings needed in context.xml for Memcached and am unsure as to what to enter in the memcachedNodes setting. Access to one of the Tomcat instances is : https://ec2-46-51-148-192.eu-west-1.compute.amazonaws.com:8443 Can you please help in defining what would need to be entered into this section of the configuration? Regards, Taj -Original Message- From: Badh, Tajvinder [mailto:tajvinder.b...@emc.com] Sent: 27 April 2011 11:19 To: Reinwald Warapen; Tomcat Users List Subject: RE: JDBCStore Persistent Manager Hi, Thank you for the suggestions. I will take try it out and let you know how it goes. Regards, Taj -Original Message- From: Reinwald Warapen [mailto:reinwal...@directi.com] Sent: 27 April 2011 10:18 To: Tomcat Users List Cc: Badh, Tajvinder Subject: Re: JDBCStore Persistent Manager I had the same requirement and tried everything possible with the Persistent Manager. I use the Memcached Session Manager (non-sticky approach) and it works brilliantly. Take a look at this which may be of help to you : http://www.reinwaldwarapen.com/2011/01/storing-and-sharing-sessions-among.html On 4/26/2011 6:54 PM, Martin Grotzke wrote: An option for such a case is memcached-session-manager with stickyness disabled: http://code.google.com/p/memcached-session-manager/ A user reported on the msm mailing list that he was trying to achieve the same what you want, also with persistentmanager, but ran into the same problem as you do. This is the thread on the msm list: http://groups.google.com/group/memcached-session-manager/browse_thread /thread/fd26a2e407c080b4 Cheers, Martin Am 26.04.2011 13:48 schrieb Badh, Tajvindertajvinder.b...@emc.com: Hi, We have an architecture such that we have 2 instances of Apache Tomcat 6 sitting under the Amazon ELB. We are having difficulties in session stickyness over HTTPS such that that requests are not being directed to the same Tomcat instance, therefore creating a new session when the request is directed to a different instance. One possible solution was to use the Tomcat JDBCStore Persistent Mananger so that session information is held centrally in a database. This did not seem to work as intended as the minimum time to write session details to the database was 10 seconds. This clearly did not solve the problem as the users interaction with the application would be less than 10 seconds. I am wating to know if there is a way to speed up the write process? I have used the FileStore and this also has the same problems. Can someone please advise in how to get this to work? The configuration in context.xml I am using is : Manager className=org.apache.catalina.session.PersistentManager distributable=true checkInterval=1 saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=0 maxIdleBackup=0 Store className=org.apache.catalina.session.JDBCStore connectionURL=connection url driverName=com.mysql.jdbc.Driver connectionName=name connectionPassword=password sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=sessions sessionValidCol=valid_session/ /Manager Thanks, Taj - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Martin Grotzke http://twitter.com/martin_grotzke signature.asc Description: OpenPGP digital signature
Re: JDBCStore Persistent Manager
An option for such a case is memcached-session-manager with stickyness disabled: http://code.google.com/p/memcached-session-manager/ A user reported on the msm mailing list that he was trying to achieve the same what you want, also with persistentmanager, but ran into the same problem as you do. This is the thread on the msm list: http://groups.google.com/group/memcached-session-manager/browse_thread/thread/fd26a2e407c080b4 Cheers, Martin Am 26.04.2011 13:48 schrieb Badh, Tajvinder tajvinder.b...@emc.com: Hi, We have an architecture such that we have 2 instances of Apache Tomcat 6 sitting under the Amazon ELB. We are having difficulties in session stickyness over HTTPS such that that requests are not being directed to the same Tomcat instance, therefore creating a new session when the request is directed to a different instance. One possible solution was to use the Tomcat JDBCStore Persistent Mananger so that session information is held centrally in a database. This did not seem to work as intended as the minimum time to write session details to the database was 10 seconds. This clearly did not solve the problem as the users interaction with the application would be less than 10 seconds. I am wating to know if there is a way to speed up the write process? I have used the FileStore and this also has the same problems. Can someone please advise in how to get this to work? The configuration in context.xml I am using is : Manager className=org.apache.catalina.session.PersistentManager distributable=true checkInterval=1 saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=0 maxIdleBackup=0 Store className=org.apache.catalina.session.JDBCStore connectionURL=connection url driverName=com.mysql.jdbc.Driver connectionName=name connectionPassword=password sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=sessions sessionValidCol=valid_session/ /Manager Thanks, Taj
