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
JDBCStore
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 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? 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
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: Tomcat 6 JDBCStore session keep being reset
On 19/06/2014 06:14, Johanes Soetanto wrote: Is there some advice on how to debug our issues? or is there some obvious configuration issue that we have? Thanks for all the advice beforehand. Check the system clocks on your production machines. Add a session listener to log the stakctrace when a session is destroyed. Add session ID to the access logs and review them for unexpectedly closed sessions. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 JDBCStore session keep being reset
Hi all, We are having problem debugging our implementation of JDBCStore session persistence. We followed guide from this post http://www.intelligrape.com/blog/2010/07/21/tomcat-6-session-persistence-through-jdbcstore/ and it works in our local machine and our test servers. When we move it on our production server, our sessions got resetted randomly. We have been trying to find out what went wrong without success. All our setup are using - Tomcat 6.0.39 using APR connector on port 8443 (SSL) and 8080 - Oracle Java 1.7.0_60-b19 - MySQL connector 5.1.21 - Application server timeout is set to 30min - Application is running using Spring Framework and Spring Security - Test and Production servers running on Linode with private ip to communicate between servers - We have Zabbix monitoring all our production and test server by pinging the app every minute (not sure how this can relate to the issue) Content of our conf/context.xml for the app servers is similar like below, while our standalone solr servers do not have the persistent manager set up. Context useHttpOnly=true Resource name=jdbc/db auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver username= password= defaultAutoCommit=false initialSize=4 maxActive=30 minIdle=4 maxIdle=4 maxWait=1 removeAbandoned=true removeAbandonedTimeout=300 validationQuery=SELECT 1 testOnBorrow=true url=jdbc:mysql://XXX.XXX.XXX.XXX:3306/app/ Manager className='org.apache.catalina.session.PersistentManager' saveOnRestart='true' minIdleSwap='0' maxIdleSwap='1' maxIdleBackup='1' Store className=org.apache.catalina.session.JDBCStore driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://XXX.XXX.XXX.XXX:3306/tomcat?user=tomcatamp;password= sessionTable=session sessionIdCol=session_id sessionDataCol=session_data sessionValidCol=valid_session sessionMaxInactiveCol=max_inactive sessionLastAccessedCol=last_access sessionAppCol='app_name' / /Manager /Context Production Environment - 1 db server (64bit) - 1 app server (32bit) connected to db server - 2 app servers (64bit) connected to db server - 2 solr servers (64bit) connected to db server Test Environment (all 64bit) - 1 app+solr+db server (combined) - 1 app+solr server connected to db server Is there some advice on how to debug our issues? or is there some obvious configuration issue that we have? Thanks for all the advice beforehand. Johanes
RE: PersistentManager + JdbcStore
I think I will fix the DynamoDB-Sessionmanager. Also an option. Already in process it seems ;) https://github.com/aws/aws-dynamodb-session-tomcat/issues/3 I hope they will use the code from tomcat for managing the classloader issues. Well, just realized that this Manager is based on PersistentManagerBase. So I see no improvement in terms of reliability, because it still writes the data async into DynamoDB. I even cannot see the reason why they created DynamoDBSessionManager, DynamoDBSessionStore would have done the job too then. Looking into the Manager interface (public void backgroundProcess()) tells me, that it seems to be always async? So what is the right stategy to distribute sessions across an arbitrary amount of servers with a 100% guarantee that the session will be found at any time on any server? Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PersistentManager + JdbcStore
On Nov 9, 2013, at 8:42 AM, spr...@gmx.eu wrote: I think I will fix the DynamoDB-Sessionmanager. Also an option. Already in process it seems ;) https://github.com/aws/aws-dynamodb-session-tomcat/issues/3 I hope they will use the code from tomcat for managing the classloader issues. Well, just realized that this Manager is based on PersistentManagerBase. So I see no improvement in terms of reliability, because it still writes the data async into DynamoDB. I even cannot see the reason why they created DynamoDBSessionManager, DynamoDBSessionStore would have done the job too then. Looking into the Manager interface (public void backgroundProcess()) tells me, that it seems to be always async? So what is the right stategy to distribute sessions across an arbitrary amount of servers with a 100% guarantee that the session will be found at any time on any server? Given some method of automatic discovery, other than multicast, it sounds like you could still use Tomcat's clustering support. So perhaps you could write your own membership service? http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/MembershipService.java?view=markup Dan 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: PersistentManager + JdbcStore
Given some method of automatic discovery, other than multicast, it sounds like you could still use Tomcat's clustering support. So perhaps you could write your own membership service? Yes, I think with Jgroups + S3 ping this could be solved. But since both ClusterManagers are based on ManagerBase too and they have to option for synchronous replication, it should be possible with a central session store (e.g. JdbcStore) too? But I cannot find the magic to replace the async background processing with sync. processing... Any idea? An alternative could be to use a servlet filter to store/load the session but this sounds a bit strange to me, because I would roll my complete own session handling solution... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PersistentManager + JdbcStore
Thanks for this post, but the problem that I have is uncertain. My application is Java Web and creates a session for the user in Tomcat (version apache-tomcat-7.0.29) and an unusual one user captures the user session without finding an explanation. Could you help me or tell me who to contact to find out how Tomcat creates and validates sessions created and if possible capture the session of another user from different computers. Best Regards 2013/11/9 spr...@gmx.eu I think I will fix the DynamoDB-Sessionmanager. Also an option. Already in process it seems ;) https://github.com/aws/aws-dynamodb-session-tomcat/issues/3 I hope they will use the code from tomcat for managing the classloader issues. Well, just realized that this Manager is based on PersistentManagerBase. So I see no improvement in terms of reliability, because it still writes the data async into DynamoDB. I even cannot see the reason why they created DynamoDBSessionManager, DynamoDBSessionStore would have done the job too then. Looking into the Manager interface (public void backgroundProcess()) tells me, that it seems to be always async? So what is the right stategy to distribute sessions across an arbitrary amount of servers with a 100% guarantee that the session will be found at any time on any server? Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: PersistentManager + JdbcStore
..Quizas.. http://kickjava.com/src/com/lutris/appserver/server/sessionContainerAdapter/JmxContainerAdapterSessionManager.java.htm (Installar como agente JMX) Saludos Cordiales Martin __ Porfavor..no altere ni interrumpir esta communication...Gracias Date: Sat, 9 Nov 2013 16:07:42 -0300 Subject: Re: PersistentManager + JdbcStore From: jbig1...@gmail.com To: users@tomcat.apache.org Thanks for this post, but the problem that I have is uncertain. My application is Java Web and creates a session for the user in Tomcat (version apache-tomcat-7.0.29) and an unusual one user captures the user session without finding an explanation. Could you help me or tell me who to contact to find out how Tomcat creates and validates sessions created and if possible capture the session of another user from different computers. Best Regards 2013/11/9 spr...@gmx.eu I think I will fix the DynamoDB-Sessionmanager. Also an option. Already in process it seems ;) https://github.com/aws/aws-dynamodb-session-tomcat/issues/3 I hope they will use the code from tomcat for managing the classloader issues. Well, just realized that this Manager is based on PersistentManagerBase. So I see no improvement in terms of reliability, because it still writes the data async into DynamoDB. I even cannot see the reason why they created DynamoDBSessionManager, DynamoDBSessionStore would have done the job too then. Looking into the Manager interface (public void backgroundProcess()) tells me, that it seems to be always async? So what is the right stategy to distribute sessions across an arbitrary amount of servers with a 100% guarantee that the session will be found at any time on any server? Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
PersistentManager + JdbcStore
Hi, is it possible to use the PersistentManager + JdbcStore to enable a 100% failover/cluster solution for sessions? As far as I can see not, because the session data is written async into the database and only in a min. interval of 1 s. Is this right? Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PersistentManager + JdbcStore
On Nov 8, 2013, at 2:14 PM, spr...@gmx.eu wrote: Hi, is it possible to use the PersistentManager + JdbcStore to enable a 100% failover/cluster solution for sessions? You could, but I'm not sure that's it's intended purpose. As I understand it, the PersistentManager is for pushing session data that hasn't been used in a while out of memory, thus allow a Tomcat server to handle more sessions with less memory. As far as I can see not, because the session data is written async into the database and only in a min. interval of 1 s. Is this right? This is my understanding as well. Sessions are persisted to the database periodically instead of on-demand. If you need sessions replicated as changes occur then you'll want to look at a different solution, like the built-in cluster support. Dan 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: PersistentManager + JdbcStore
If you need sessions replicated as changes occur then you'll want to look at a different solution, like the built-in cluster support. Unfortunately it does not work on AWS, no multicast. I think I will fix the DynamoDB-Sessionmanager. Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PersistentManager + JdbcStore
On Nov 8, 2013, at 2:41 PM, spr...@gmx.eu wrote: If you need sessions replicated as changes occur then you'll want to look at a different solution, like the built-in cluster support. Unfortunately it does not work on AWS, no multicast. Multicast is not a requirement, that just defines how Tomcat nodes will locate each other. Since multicast is not available for you, you could statically list your Tomcat nodes in your configuration. https://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Static_Membership I think I will fix the DynamoDB-Sessionmanager. Also an option. I think there is a similar items for Redis and MongoDb too. I've not used any of them though, so I can't comment on their fitness. Dan 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: PersistentManager + JdbcStore
Multicast is not a requirement, that just defines how Tomcat nodes will locate each other. Since multicast is not available for you, you could statically list your Tomcat nodes in your configuration. https://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interc eptor.html#Static_Membership a) Since instances come up and down occasionally and IPs are not fixed, this is not an option on AWS. b) Furthermore DeltaManager is not applicable for large instances counts and BackupManager is impossible too, because of a). I think I will fix the DynamoDB-Sessionmanager. Also an option. Already in process it seems ;) https://github.com/aws/aws-dynamodb-session-tomcat/issues/3 I hope they will use the code from tomcat for managing the classloader issues. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: PersistentManager + JdbcStore
On 09/11/2013 6:41 AM, spr...@gmx.eu wrote: If you need sessions replicated as changes occur then you'll want to look at a different solution, like the built-in cluster support. Unfortunately it does not work on AWS, no multicast. Cant you use static membership instead mcast? I think I will fix the DynamoDB-Sessionmanager. Thank you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Thread starvation with JDBCStore
We will provide the patch for Tomcat 7, is that ok or should it be on master for Tomcat 8? We won't be updating to Tomcat 7 for a month, so we won't provide the patch until we have fully tested it. We updated LocalString.properties for our new messages but did not update the other languages since we are not fluent in those. Is that OK? What should we do about the documentation for JDBCStore? Should we say that it is deprecated and to use DataSourceStore instead? Or leave it and update the documentation to talk about both? If you are interested you can look at the preliminary changes here. https://github.com/kdombeck/tomcat70/tree/datasource-session-store From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, November 6, 2012 4:22 PM Subject: Re: Thread starvation with JDBCStore 2012/11/7 ken dombeck ken_domb...@yahoo.com: #1 I can definetly create a new store (JDBCRealm, DataSourceRealm), I am just not sure of Apache wanting to support multiple implementations. It is not a big deal. If the new implementation is better we can deprecate the old one and remove it from future versions. I just do not see how all issues can be solved just by patching JDBCStore. For such components the support is mostly a supervision. The bug reports and patches are usually provided by those who are actually using the component. #3 Sorry, I should have mentioned that we tested all 3 options and option 1 and 3 solved our issue. Option 2 helped a bit but was not completely fair to all threads and therefore still allowed the background process to hold the lock longer than expected. OK, feel free to submit a patch. #4 Increasing the expire frequency is our current short term hack. This is a hack because it does not remove the problem, it just reduces the frequency of the issue. #5 I have found several issues opened for the performance issues of expiring database sessions. This could be a future enhancement but does not completely solve this issue. https://issues.apache.org/bugzilla/show_bug.cgi?id=34319 https://issues.apache.org/bugzilla/show_bug.cgi?id=47281 BZ 47281 has the same idea that I mentioned, to use a SELECT WHERE. ;) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Thread starvation with JDBCStore
2012/11/5 ken dombeck ken_domb...@yahoo.com:
Occasionally when a user signs into our web site it is taking a very long
time to create a session (10 to 100+ seconds). We traced the issue do to the
fact that the background process (ContainerBackgroundProcessor) calls
PersistentManagerBase.processExpires() to swap out sessions from memory and
remove expired sessions from the database. The issue only appears when we
have 10’s of thousands of sessions in memory/database.
The problem is that even though StoreBase.processExpires() correctly releases
the locks from JDBCStore (load and remove methods) JDK 6 has implemented
“bias locking”
http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5 which
causes this process to ‘hold’ onto the locks obtained in JDBCStore until it
is completely done.
It is this thread starvation, when the background process
(ContainerBackgroundProcessor) expires/swaps out session runs that other
threads are prevented from load sessions from the database due to the locks
obtained in JDBCStore.
We are running Tomcat 6.0, OpenJDK 6 (same problem with OpenJDK 7), Ubuntu
10.04.
The problem appears to be a JDK issue that is explained very well in this
blog post.
http://ceki.blogspot.com/2009/06/biased-locking-in-java-se-60.html
Reading the blog and looking at the JDK bug tracker it does not appear that
the issue will be fixed either.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4985566
We have come up with a few solutions to this issue that work and would like
the community’s input prior to submitting a patch.
1) Connection Pool - currently in Tomcat 6.0 JDBCStore only takes a
connectionURL. In Tomcat 7.0 this has been changed to be a connectionURL or
dataSourceName. If connectionURL were to be removed from this class and a
connection pool were to be used for dataSourceName, then the synchronization
could be completely removed from this class.
Pros: Completely removing the global synchronization improves concurrency
which is moved to the JDBC pool implementation instead.
Cons: The main issue with this solution is that it would affect all existing
configurations that use connectionURL.
2) Thread priority - By allowing a user to specify the priority of the
background process (ContainerBackgroundProcessor) to be a lower priority than
other threads the JVM will allow those other threads to obtain the lock
occasionally. This did not work as well as the other solutions since the JVM
did not relinquish control from the background thread to the other worker
threads as often as we would have liked.
Pros: This would solve any synchronization issues other than just JDBCStore
for the entire background process.
Cons: With the background thread set to a lower priority the other worker
threads only obtained a time slice ever 3 seconds unlike milliseconds for the
other implementations. Thread priority could also be dependent on the JVM
implementation/platform.
3) Fair lock - By replacing the synchronization blocks in JDBCStore with
java.util.concurrent.locks.ReentrantLock and constructing the lock with
fair=true we would allow each thread to get the appropriate time slice.
Pros: This could be written in a way that would default to fair=false to
maintain the default behaviour. A configuration parameter could be added to
allow for the setting of the fair flag.
Cons: May be a small performance penalty.
Our proposal is solution #3.
Let me know your thoughts and we will supply a patch.
1) I'd prefer #1, though it might be easier to implement a separate
class rather than patch this one (like JDBCRealm vs DataSourceRealm).
Currently there are a number of fields in JDBCStore that cannot be
used by more than one thread (e.g. JDBCStore#preparedKeysSql and other
PreparedStatement s there). Such changes will change API, so it is
better to write a separate class.
Disclamer: I have not looked whether such multithreading makes sense
for an org.apache.catalina.Store. I have not reviewed that API.
2) BTW, I wonder whether the following pattern in JDBCStore
synchronized (this) {
Connection _conn = getConnection();
}
may be responsible for some Sessions are not expiring threads that I
see on the users list. E.g.
http://markmail.org/thread/jkbbiqpxodefpm6i
(Though we are still waiting for a thread dump in that thread, so
currently it is not known what the problem is).
A common mistake with DBCP pool is to configure an infinite timeout there.
3) Have you tested that #3 solves your problem?
IMO, changing synchronization object is a slight API change (from the
POV of child classes). I would not object to it though if it solves a
real problem and the lock object is available to the child classes.
4) It is possible to configure the background thread to run more rarely.
It is also possible to configure separate background thread per
container. You can have
Re: Thread starvation with JDBCStore
#1 I can definetly create a new store (JDBCRealm, DataSourceRealm), I am just not sure of Apache wanting to support multiple implementations. #2 I don't think this issue is the cause for the mail thread that you listed. That mail thread does not talk about persisting sessions to the database. But maybe it could be. #3 Sorry, I should have mentioned that we tested all 3 options and option 1 and 3 solved our issue. Option 2 helped a bit but was not completely fair to all threads and therefore still allowed the background process to hold the lock longer than expected. #4 Increasing the expire frequency is our current short term hack. This is a hack because it does not remove the problem, it just reduces the frequency of the issue. #5 I have found several issues opened for the performance issues of expiring database sessions. This could be a future enhancement but does not completely solve this issue. https://issues.apache.org/bugzilla/show_bug.cgi?id=34319 https://issues.apache.org/bugzilla/show_bug.cgi?id=47281 Thanks for your help. Let me know your thoughts and we will open a ticket in the issue tracker and submit a patch. From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, November 6, 2012 11:24 AM Subject: Re: Thread starvation with JDBCStore 2012/11/5 ken dombeck ken_domb...@yahoo.com: Occasionally when a user signs into our web site it is taking a very long time to create a session (10 to 100+ seconds). We traced the issue do to the fact that the background process (ContainerBackgroundProcessor) calls PersistentManagerBase.processExpires() to swap out sessions from memory and remove expired sessions from the database. The issue only appears when we have 10’s of thousands of sessions in memory/database. The problem is that even though StoreBase.processExpires() correctly releases the locks from JDBCStore (load and remove methods) JDK 6 has implemented “bias locking” http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5 which causes this process to ‘hold’ onto the locks obtained in JDBCStore until it is completely done. It is this thread starvation, when the background process (ContainerBackgroundProcessor) expires/swaps out session runs that other threads are prevented from load sessions from the database due to the locks obtained in JDBCStore. We are running Tomcat 6.0, OpenJDK 6 (same problem with OpenJDK 7), Ubuntu 10.04. The problem appears to be a JDK issue that is explained very well in this blog post. http://ceki.blogspot.com/2009/06/biased-locking-in-java-se-60.html Reading the blog and looking at the JDK bug tracker it does not appear that the issue will be fixed either. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4985566 We have come up with a few solutions to this issue that work and would like the community’s input prior to submitting a patch. 1) Connection Pool - currently in Tomcat 6.0 JDBCStore only takes a connectionURL. In Tomcat 7.0 this has been changed to be a connectionURL or dataSourceName. If connectionURL were to be removed from this class and a connection pool were to be used for dataSourceName, then the synchronization could be completely removed from this class. Pros: Completely removing the global synchronization improves concurrency which is moved to the JDBC pool implementation instead. Cons: The main issue with this solution is that it would affect all existing configurations that use connectionURL. 2) Thread priority - By allowing a user to specify the priority of the background process (ContainerBackgroundProcessor) to be a lower priority than other threads the JVM will allow those other threads to obtain the lock occasionally. This did not work as well as the other solutions since the JVM did not relinquish control from the background thread to the other worker threads as often as we would have liked. Pros: This would solve any synchronization issues other than just JDBCStore for the entire background process. Cons: With the background thread set to a lower priority the other worker threads only obtained a time slice ever 3 seconds unlike milliseconds for the other implementations. Thread priority could also be dependent on the JVM implementation/platform. 3) Fair lock - By replacing the synchronization blocks in JDBCStore with java.util.concurrent.locks.ReentrantLock and constructing the lock with fair=true we would allow each thread to get the appropriate time slice. Pros: This could be written in a way that would default to fair=false to maintain the default behaviour. A configuration parameter could be added to allow for the setting of the fair flag. Cons: May be a small performance penalty. Our proposal is solution #3. Let me know your thoughts and we will supply a patch. 1) I'd prefer #1, though it might be easier
Re: Thread starvation with JDBCStore
2012/11/7 ken dombeck ken_domb...@yahoo.com: #1 I can definetly create a new store (JDBCRealm, DataSourceRealm), I am just not sure of Apache wanting to support multiple implementations. It is not a big deal. If the new implementation is better we can deprecate the old one and remove it from future versions. I just do not see how all issues can be solved just by patching JDBCStore. For such components the support is mostly a supervision. The bug reports and patches are usually provided by those who are actually using the component. #3 Sorry, I should have mentioned that we tested all 3 options and option 1 and 3 solved our issue. Option 2 helped a bit but was not completely fair to all threads and therefore still allowed the background process to hold the lock longer than expected. OK, feel free to submit a patch. #4 Increasing the expire frequency is our current short term hack. This is a hack because it does not remove the problem, it just reduces the frequency of the issue. #5 I have found several issues opened for the performance issues of expiring database sessions. This could be a future enhancement but does not completely solve this issue. https://issues.apache.org/bugzilla/show_bug.cgi?id=34319 https://issues.apache.org/bugzilla/show_bug.cgi?id=47281 BZ 47281 has the same idea that I mentioned, to use a SELECT WHERE. ;) Best regards, Konstantin Kolinko - 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
JDBCStore Persistent Manager
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
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
Re: Session replication using only PersistenceManager + JDBCStore
Thanks for your detailed answer, I will probably go with in-memory replication. Regading your last question, I have one database instance sitting on top of a 2 node DRBD. 2009/6/17 Christopher Schultz ch...@christopherschultz.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yves, On 6/17/2009 6:04 AM, Yves Glodt wrote: In my setup are 4 apaches with mod_proxy which connect to 4 tomcats. In front of the apaches is a hardware balancer which does round-robin, but with a kind of sticky TCP-sessions, so mostly the clients on the web stay on the same server. Mostly... Why not use mod_jk's session stickiness? The httpd server can be chosen randomly by the hw lb, but the right Tomcat always gets the request. Then, you can forget about session replication and get better performance. On the other hand, if your users cannot be expected to tolerate interruptions (due to a failing server) then you'll /have/ to go with some kind of replication. To be completely safe and sleep well, I would like to replicate the sessions now, and in the mentioned document I read that it is possible using the PersistenceManager with JDBCStore. Just note that this is probably the slowest of the 3 options presented in the Replication HOWTO, since each session attribute will have to be retrieved from the database every time. Option #3 (in-memory replication) will probably be the fastest option for a cluster such as yours, especially if all the members of the cluster are on the same (real) network. My question now: Is it enough to set up PersistenceManager with JDBCStore on my 4 tomcats to use the same database/table as session store ? It should be. Or do I need to mess with ReplicationValve and jvmRoute set up as well ? No, but I think using real replication will give you better performance. I will put my server.xml at the end of the file, which is set up with JDBCStore using a Firebird Database with JayBird. How are you sharing your database across your 4 Tomcat instances? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5RwoACgkQ9CaO5/Lv0PDK/wCffEK2IfLU3urah7UO4c8+NV2w VOMAn2ly1yE2CO3+PdglPRj2k9plFn5F =qeVK -END PGP SIGNATURE- - 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
Session replication using only PersistenceManager + JDBCStore
Hello, I am currently trying to set up session replication, and reading this document [1], but a few questions remain. In my setup are 4 apaches with mod_proxy which connect to 4 tomcats. In front of the apaches is a hardware balancer which does round-robin, but with a kind of sticky TCP-sessions, so mostly the clients on the web stay on the same server. Mostly... To be completely safe and sleep well, I would like to replicate the sessions now, and in the mentioned document I read that it is possible using the PersistenceManager with JDBCStore. My question now: Is it enough to set up PersistenceManager with JDBCStore on my 4 tomcats to use the same database/table as session store ? Or do I need to mess with ReplicationValve and jvmRoute set up as well ? I will put my server.xml at the end of the file, which is set up with JDBCStore using a Firebird Database with JayBird. Best regards, Yves [1] http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html Server.xml which I use for testing: Server port=8005 shutdown=SHUTDOWN Service name=Testing Connector port=8181 / Engine name=testing defaultHost=localhost Host name=localhost debug=99 appBase=/storage/tomcat unpackWARs=true autoDeploy=true Context path=/HelloWorld docBase=HelloWorld debug=99 reloadable=false distributable=true Manager className=org.apache.catalina.session.PersistentManager debug=99 distributable=true maxActiveSessions=-1 maxIdleBackup=10 maxIdleSwap=15 minIdleSwap=5 maxInactiveInterval=1800 saveOnRestart=true Store className=org.apache.catalina.session.JDBCStore driverName=org.firebirdsql.jdbc.FBDriver connectionURL=jdbc:firebirdsql:myhighavailablefirebirdserver:tomcat_sessions?userName=SYSDBAamp;password=masterkeyamp;encoding=UTF8 sessionTable=session sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionValidCol=valid_session debug=99 checkInterval=60 / /Manager /Context /Host /Engine /Service /Server - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session replication using only PersistenceManager + JDBCStore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yves, On 6/17/2009 6:04 AM, Yves Glodt wrote: In my setup are 4 apaches with mod_proxy which connect to 4 tomcats. In front of the apaches is a hardware balancer which does round-robin, but with a kind of sticky TCP-sessions, so mostly the clients on the web stay on the same server. Mostly... Why not use mod_jk's session stickiness? The httpd server can be chosen randomly by the hw lb, but the right Tomcat always gets the request. Then, you can forget about session replication and get better performance. On the other hand, if your users cannot be expected to tolerate interruptions (due to a failing server) then you'll /have/ to go with some kind of replication. To be completely safe and sleep well, I would like to replicate the sessions now, and in the mentioned document I read that it is possible using the PersistenceManager with JDBCStore. Just note that this is probably the slowest of the 3 options presented in the Replication HOWTO, since each session attribute will have to be retrieved from the database every time. Option #3 (in-memory replication) will probably be the fastest option for a cluster such as yours, especially if all the members of the cluster are on the same (real) network. My question now: Is it enough to set up PersistenceManager with JDBCStore on my 4 tomcats to use the same database/table as session store ? It should be. Or do I need to mess with ReplicationValve and jvmRoute set up as well ? No, but I think using real replication will give you better performance. I will put my server.xml at the end of the file, which is set up with JDBCStore using a Firebird Database with JayBird. How are you sharing your database across your 4 Tomcat instances? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5RwoACgkQ9CaO5/Lv0PDK/wCffEK2IfLU3urah7UO4c8+NV2w VOMAn2ly1yE2CO3+PdglPRj2k9plFn5F =qeVK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieve session data stored in db using JDBCStore.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry, On 4/15/2009 11:58 PM, jerrySheen wrote: So u mean to say, that if I were to prolong the JSESSIONID cookie's expiry time, the server would take care of repopulating the session state(stored in the db) even after a browser restart? Well, this seems like a much simpler solution,ill give it a try, hope it works. You have to modify the cookie that Tomcat creates. By default, the cookie has a max age of -1, which means forget me when the browser closes. Note that this is different than the maxInactiveInterval for the session itself, which is the expiration date for the /session/ (no the cookie). You'll have to write a filter or something like that to modify the cookie sent to the browser. You want to grab the appropriate cookie and change the max age to something else. You probably want to make it something like tomorrow (relative to today, of course) so that the cookie is persisted across browser restarts. Note that an expired session on the server side is non-recoverable. Good luck. Post back if you develop a decent solution. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknooOEACgkQ9CaO5/Lv0PDVIQCeL/EVSixGDiz02Orzk4LuxLKa K08AoKqmrENfD1zsh17+3eWgLkClQhhT =RG+p -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieve session data stored in db using JDBCStore.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry, On 4/13/2009 11:15 PM, jerrySheen wrote: As we are dealing with sessions that are no [longer accessible], this action would have no effect on any live sessions thus no inconsistencies. if YES, please furnish some sample code or at least direct me towards the solutions. You could certainly look at the code for the org.apache.catalina.session.JDBCStore class. Isn't [something already] happening now? Yes but only at server restarts. Server restarts or browser restarts? what i am trying to implement here is session persistence across browser restarts. ie. I would like to maintain the session state even if the browser is closed and restarted at which point a new session is started. I think you want to change the cookie behavior, not go mucking-around with the session itself. All you really need is the browser to remember the JSESSIONID cookie across a browser restart. now i would like to persist the old session by maintaining the session id inside a cookie, and compare this id against the session id stored in 'sessionIdCol=id ', then copy the session data stored as blob in '''sessionDataCol = data ' and assign this data to the new session. This seems like more work than necessary. Why not fix the JSESSIONID cookie? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknmkxUACgkQ9CaO5/Lv0PCu/ACffl4CPLTEISX8Ri4IAMmVOt61 DlIAn2zwanuZYdBxJjQ85nCeum5f555K =l8Ey -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieve session data stored in db using JDBCStore.
So u mean to say, that if I were to prolong the JSESSIONID cookie's expiry time, the server would take care of repopulating the session state(stored in the db) even after a browser restart? Well, this seems like a much simpler solution,ill give it a try, hope it works. Thanks, JS -- View this message in context: http://www.nabble.com/retrieve-session-data-stored-in-db-using-JDBCStore.-tp23020556p23071047.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieve session data stored in db using JDBCStore.
can someone please reply to the above post.:-(( -- View this message in context: http://www.nabble.com/retrieve-session-data-stored-in-db-using-JDBCStore.-tp23020556p23052044.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
retrieve session data stored in db using JDBCStore.
Hi, I have been successful in saving the sessions to my mysql db, using the given code in my server configuration file. Store className=org.apache.catalina.session.JDBCStore connectionURL=jdbc:mysql://X/xx?user=zamp;password=zz driverName=com.mysql.jdbc.Driver sessionIdCol=id sessionValidCol=valid sessionMaxInactiveCol=maxinactive sessionLastAccessedCol=lastaccess sessionTable = app_sessions sessionAppCol = context sessionDataCol = data / this stores the session data as a blob in the db. So my questions are, Can we assign the blob data directly to a new session, so that this new session assumes the state of the session in the db? Can we retrieve and edit information from the blob? if YES, please furnish some sample code or at least direct me towards the solutions. if NO, what other ways can we go about, to achieve session persistence(not just validation as in cookies but a complete session state snapshot). -- View this message in context: http://www.nabble.com/retrieve-session-data-stored-in-db-using-JDBCStore.-tp23020556p23020556.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieve session data stored in db using JDBCStore.
jerrySheen wrote: Hi, I have been successful in saving the sessions to my mysql db, using the given code in my server configuration file. Store className=org.apache.catalina.session.JDBCStore connectionURL=jdbc:mysql://X/xx?user=zamp;password=zz driverName=com.mysql.jdbc.Driver sessionIdCol=id sessionValidCol=valid sessionMaxInactiveCol=maxinactive sessionLastAccessedCol=lastaccess sessionTable = app_sessions sessionAppCol = context sessionDataCol = data / this stores the session data as a blob in the db. So my questions are, Can we assign the blob data directly to a new session, so that this new session assumes the state of the session in the db? Why? The session manager should be doing this for you. Can we retrieve and edit information from the blob? Why? The risk is that you will introduce inconsistencies into live sessions. Surely modifying the session using the API provided by the Servlet spec is a) safer and b) easier. if YES, please furnish some sample code or at least direct me towards the solutions. if NO, what other ways can we go about, to achieve session persistence(not just validation as in cookies but a complete session state snapshot). Isn't that happening now? p p.s. tomcat version, jvm version, os version? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retrieve session data stored in db using JDBCStore.
Why? The risk is that you will introduce inconsistencies into live sessions. Surely modifying the session using the API provided by the Servlet spec is a) safer and b) easier. As we are dealing with sessions that are no more accessable, this action would have no effect on any live sessions thus no inconsistencies. if YES, please furnish some sample code or at least direct me towards the solutions. if NO, what other ways can we go about, to achieve session persistence(not just validation as in cookies but a complete session state snapshot). Isn't that happening now? Yes but only at server restarts. Can we assign the blob data directly to a new session, so that this new session assumes the state of the session in the db? Why? The session manager should be doing this for you. Again this happens only at server restarts. tomcat version = 5.5.20, jvm version = 1.6.0, os version = windows xp sp2. Ok. what i am trying to implement here is session persistence across browser restarts. ie. I would like to maintain the session state even if the browser is closed and restarted at which point a new session is started. we know that the session exists in the db for the time that is specified in 'sessionMaxInactiveCol=maxinactive ' so, even if the browser is closed and the session is destroyed at browser level it still exists in the db. (we can prolong session expiry using: session.setMaxInactiveInterval(2 weeks);) now i would like to persist the old session by maintaining the session id inside a cookie, and compare this id against the session id stored in 'sessionIdCol=id ', then copy the session data stored as blob in '''sessionDataCol = data ' and assign this data to the new session. thus i would be able to regain the last session state in which the browser was closed. once the transaction is complete i would remove the old session from the db. Is this possible, if yes how? -- View this message in context: http://www.nabble.com/retrieve-session-data-stored-in-db-using-JDBCStore.-tp23020556p23032552.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Session Persistence via JDBCStore
Hi, I currently use deployment descriptor xml files to describe both the war file to deployed and the session persistence info (configs+db info). Currently we use a connectionURL that specifies db complete db info (user/pass/db/port/sid)-- I would like to know if I can specify a datasource specified in the server.xml instead, and how to specify it (if you could provide an example, that'd be great). Here's an example of my current deployment descriptor: mywar.xml Context path=/mywar docBase=/nas1/tomcat/apps/mywar.war Manager className=org.apache.catalina.session.PersistentManager maxIdleBackup=1 maxIdleSwap=1780 maxInactiveInterval=1800 minIdleSwap=1750 processExpiresFrequency=1 Store className=org.apache.catalina.session.JDBCStore connectionURL=jdbc:oracle:thin:user/passw...@mydberver.mydomain.com:1521:DBSID driverName=oracle.jdbc.driver.OracleDriver sessionAppCol=app_context sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=tomcat_sessions sessionValidCol=valid_session/ /Manager /Context Thanks!!! Eddie _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme
Re: Session Persistence via JDBCStore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eddie, On 3/27/2009 11:23 AM, Eddie Yee wrote: I currently use deployment descriptor xml files to describe both the war file to deployed and the session persistence info (configs+db info). Currently we use a connectionURL that specifies db complete db info (user/pass/db/port/sid)-- I would like to know if I can specify a datasource specified in the server.xml instead, and how to specify it (if you could provide an example, that'd be great). Unfortunately, JDBCStore does not support the use of DataSources. I would have recommended that you just subclass JDBCStore and override the 'open' method, but it looks like that class (like it's brother JDBCRealm) caches PreparedStatement objects so you might have do to a bunch of work to subclass... perhaps just copying that class and doing a hack-job on it would work. If you were to write something like this, consider contributing it back to the community... I'm sure some people out there would like to use a JDBCDataSourceStore instead of the JDBCStore. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknM9QMACgkQ9CaO5/Lv0PC2jACghE0mGGOl1FgE8ZVqvVzfNLn3 QUwAoIhdx6JPOxRSf+7Zd8XOCI8JDbV7 =sduq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Persistence via JDBCStore
Hi Eddie, I'm not sure if this would be possible with the default JDBCStore shipped with tomcat since the org.apache.catalina.session.JDBCStore is not considering usage of datasources which would certainly be a good plus, but maybe there is a reason why it is not in there. if some one else have a clue i'm interested to know how this work. On Fri, Mar 27, 2009 at 4:23 PM, Eddie Yee eddieyeew...@hotmail.com wrote: Hi, I currently use deployment descriptor xml files to describe both the war file to deployed and the session persistence info (configs+db info). Currently we use a connectionURL that specifies db complete db info (user/pass/db/port/sid)-- I would like to know if I can specify a datasource specified in the server.xml instead, and how to specify it (if you could provide an example, that'd be great). Here's an example of my current deployment descriptor: mywar.xml Context path=/mywar docBase=/nas1/tomcat/apps/mywar.war Manager className=org.apache.catalina.session.PersistentManager maxIdleBackup=1 maxIdleSwap=1780 maxInactiveInterval=1800 minIdleSwap=1750 processExpiresFrequency=1 Store className=org.apache.catalina.session.JDBCStore connectionURL=jdbc:oracle:thin:user/passw...@mydberver.mydomain.com:1521:DBSID driverName=oracle.jdbc.driver.OracleDriver sessionAppCol=app_context sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=tomcat_sessions sessionValidCol=valid_session/ /Manager /Context Thanks!!! Eddie _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- -- Yassine Elassad Bonn, Germany. Fon : +49 228 97629355 Mobile : +49 157 74519666 PEACE : ( P ) Positive ( E ) Energy ( A ) Always ( C ) Correct ( E ) Errors. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Session Persistence via JDBCStore
Ya, right now it's a really big pain in the rear to maintain all these extra configs, especially when we jump between different databases when they go under maintenance, and multiply that between the number of applications we have now... If anybody else knows a way around this, I'd appreciate it. Hi Eddie, I'm not sure if this would be possible with the default JDBCStore shipped with tomcat since the org.apache.catalina.session.JDBCStore is not considering usage of datasources which would certainly be a good plus, but maybe there is a reason why it is not in there. if some one else have a clue i'm interested to know how this work. _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009
Tomcat 6.0.14 PersistentManager/JDBCStore
Greetings, all I might be completely off track (hope not!), but I am trying to achieve session replication by using JDBCStore and PersistentManager with a shared database. I noticed that the sessions are not persisted in database until I stop the application (or stop Tomcat) and this is a problem for me since I want to use this session replication as a mean to clustering. (instead of using SimpleTcpCluster) Has anybody succeeded using database as session storage while having several tomcat instances sharing one? (and achieving clustering in effect?) My configs: Tomcat 6.0.14 Java 6 DB: mysql 5 context.xml used in my application Context path=/LocalhostTest distributable=true Manager className=org.apache.catalina.session.PersistentManager saveOnRestart=true Store className=org.apache.catalina.session.JDBCStore driverName=com.mysql.jdbc.Driver connectionName=sessionManager connectionPassword=smPassword connectionURL=jdbc:mysql://localhost:3306/sessions sessionAppCol=app_name sessionDataCol=session_data sessionIdCol=session_id sessionLastAccessedCol=last_access sessionMaxInactiveCol=max_inactive sessionTable=tomcat_sessions sessionValidCol=valid_session / /Manager /Context Thank you for help. Timothy Wonil Lee Java Developer Koorong Books (http://www.koorong.com/) email: [EMAIL PROTECTED] direct ph: (+612) 9857 4448 direct fax: (+612) 9857 6648 http://timundergod.blogspot.com/ http://www.google.com/reader/shared/16849249410805339619 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
