tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: tomcat dB persistant session store delay
Date Thu, 18 Aug 2016 20:00:02 GMT
-----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 < 
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message