-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gibu,
On 8/18/16 12:45 PM, Gibu George wrote: > On Thu, Aug 18, 2016 at 9:17 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Gibu, > > On 8/18/16 10:55 AM, Gibu George wrote: >>>> I have setup a tomcat cluster that store the session >>>> information in a mysql dB. I also have a load balancer in >>>> front of this cluster. >>>> >>>> I have noticed a delay, in few seconds, before the session >>>> information is stored in the dB. Is there any way to reduce >>>> this delay and get tomcat to store the session information, >>>> in the dB, instantly? >>>> >>>> One of the threads in the tomcat archives talks about >>>> "synchronous session replication" ( ( >>>> https://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html#Cluster _Co > >>>> nfiguration_for_ReplicationTransmitter_(_synchronous_-_mode) >>>> >>>> > ) ) . Is this still a valid configuration for tomcat8.0 ? > > Are you wanting to speed-up replication across the cluster, or the > writes to the database-backed store? Or both? > > >> Both, speed-up replication across the cluster and reduce the time >> to write to dB Okay, so you do really want cluster replication (for fail-over, potentially load-balancing). Okay. Do you need durable sessions? If you had fast clustered-replication, would that be good enough? I just want to make sure you really need what you are asking for, or if you have gotten to this point because you are trying several ways to share data between nodes. >>>> My setup works fine when the load balancer is configured >>>> with sticky sessions. When sticky sessions are removed, i am >>>> facing issues in logging into the application thats hosted on >>>> my tomcat cluster. I believe this is due to the delay in >>>> storing the session information in dB. Is this right? > > Is there a problem using sticky sessions? Sticky sessions are > pretty much always a good idea since they solve many of these > problems. Use of sticky sessions does not preclude > fail-over-without-re-login. > > >> I am facing no major issue at this point with a sticky load >> balancer, though at times I see most of the requests going to >> just one machine and the other one almost at idle. Thought of >> better load distribution across the instances without a sticky >> load balancer. What is acting as your load-balancer? We use httpd + mod_jk and it does a seemingly fair job of balancing sessions. I have no hard data for that, though collecting it wouldn't be too hard. > Can you post your existing configuration? > >> Setup in AWS, so static clustering server.xml : >> https://gist.github.com/141984/2c2d112afc8115de82c6f659df21cec6 For the impatient: > <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" > channelSendOptions="8"> Cluster's channelSendOptions defaults to "8", but I see you have been trying to force it. I think this setting is for communication in general between the nodes, not specifically for synchronous session-replication. I think that's configured in the Manager you are using. It's possible that this comment in the docs: " The default value [for Manager className] is the org.apache.catalina.ha.session.DeltaManager that is closely coupled with the SimpleTcpCluster implementation. Other managers like the org.apache.catalina.ha.session.BackupManager are/could be loosely coupled and don't rely on the SimpleTcpCluster for its data replication. " Perhaps that means that Cluster's channelSendOptions affects how the DeltaManager performs its replication. > <Manager className="org.apache.catalina.ha.session.DeltaManager" > expireSessionsOnShutdown="false" > notifyListenersOnReplication="true"/> The BackupManager's mapSendOptions default is "6" which means "synchronous". I don't see a similar option in the DeltaManager, and I'm not familiar enough with it to know how it will behave. Can you confirm that you are getting HTTP responses before the cluster has fully-replicated your session changes? I'm assuming that the <Channel> and everything are okay, since your cluster appears to be *working* -- that is, messages do in fact flow... you just want them to flow slightly differently. >> context.xml: >> https://gist.github.com/141984/7d0b1bbb7acc3131236d981d0f737ded > > For the impatient: > > <Manager className="org.apache.catalina.session.PersistentManager" > maxIdleBackup="0"> <Store > className="org.apache.catalina.session.JDBCStore" > connectionName="flintstones" connectionPassword="barney" > connectionURL="jdbc:mysql://7.1.3.9:3306/mysessions" > driverName="com.mysql.jdbc.Driver" sessionTable="tomcat_sessions" > sessionAppCol="app_name" sessionDataCol="session_data" > sessionIdCol="session_id" sessionLastAccessedCol="last_access" > sessionMaxInactiveCol="max_inactive" > sessionValidCol="valid_session" /> </Manager> I highly recommend that you use a DataSource with your JDBC store, though that is only based upon the knowledge that the JDBCRealm has poor performance because it uses a single JDBC Connection for all of its work. If you use a DataSourceRealm you get better performance. You might try that with JDBCStore to see if it makes a difference. I see no way to particular way to make JDBCStore synchronous: to refuse to return a page to the client until after session data has been written. I'm going to rely on Keiichi to help explain the behavior of the cluster and the associated manager. You could try using BackupManager with mapSendOptions="6" (the default). Hope that helps (a little), - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXthPCAAoJEBzwKT+lPKRYuXYP/idpY7TUreysfyRRnQ1P+UjG ea+KGk07uAZrPZZ5wEXuWFb7FtihDyzKWOwSkMIiGSgyft3MLzOBmI8N+u6274MF 4KshA2PZgN8pzhB9liiAyujVDrJ48YXJSC9B+V4+41wleN+snqO8OpBWrlgejssz aHGy//PH0oa65/HDb8+oEhMkYQpkcSCj/wI2At8+/2fQAcuUMNypOpcY4VKWzskh NTOdcsbYwZOw5C+BmTLbL8MNfE9juj/1x1RpzGm7PyeS4jFNZWsG6x9+ZvamhrKZ /zY9+pBiN11bYQk5P6y1XwOHFEfjfKXAoDwiITUn/x5m8a7X4af9pNFZjlxvFtIj KdfmY8d4YKCJVsnvaZ6PUC4HZSciMxDGfOUrd3twLbtvHhjgABGj7znymDimpiYX rMK2/9yA9gCDNt88B0YphcqauHM59G7pHtX7OzIR0TGXaB29h1S22Ah1E7QpOHbr imK6M5oa4b/X5QBlx/4swyIHTPoWomyf1pASoKapG4zxGRi3BC0OTFzoUHEf79fj vxiEo4arXq7BXKxphBHVAHPggu3eXQ7idKUACDVSLhyi+0jnv9rM3JsKcXxAM21G oxUTXFwVq/ZJOADPaHt4YuE4Kwcf4ZMrff8+5WD3YrBO3rb5nkQ6v77Z//mlS3n6 8Dardi4KVuEpaOzbBBsw =phlv -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
