You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Gibu George <gi...@gmail.com> on 2016/08/18 14:55:42 UTC
tomcat dB persistant session store delay
Hi All,
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_Configuration_for_ReplicationTransmitter_(_synchronous_-_mode)
) ) . Is this still a valid configuration for tomcat8.0 ?
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?
--
--gibu
Re: tomcat dB persistant session store delay
Posted by Gibu George <gi...@gmail.com>.
Hello Christopher,
thanks for the reply,
i will try out DataSource with the JDBCStore and see if that makes any
difference.
I haven't tried out BackupManager because, according to the documentation,
it replicates the session data to only backup node. So I'm not sure if all
my clusters in a more-than-2 cluster setup would have the session data. (
https://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html )
I'm currently using AWS LB and the distribution of load is not fair at
times. That being said I have no working issues with a sticky load
balancer, just trying to see if I can get the session information
replicated and stored faster.
How do I get fast cluster replication, I can try and see if that solves my
"problem" as well :)
--gibu
On Fri, Aug 19, 2016 at 1:30 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----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
>
>
--
--gibu
Re: tomcat dB persistant session store delay
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: tomcat dB persistant session store delay
Posted by Gibu George <gi...@gmail.com>.
On Thu, Aug 18, 2016 at 9:17 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
>
> > 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.
>
> Can you post your existing configuration?
>
Setup in AWS, so static clustering
server.xml : https://gist.github.com/141984/2c2d112afc8115de82c6f659df21cec6
context.xml: https://gist.github.com/141984/7d0b1bbb7acc3131236d981d0f737ded
--gibu
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXtdiCAAoJEBzwKT+lPKRYkfEP/1KK1BNjDbE20L9pBS9i5NTV
> B2A7IxN0F7D14QmBVgEe1RO3uB+e2XyS6up4S2VOW1g+YMUj2p2VoBjs6zfiIeQX
> VlRkFbz9zyrHwhliR7BrM9fI510a9Tzq+upML1uwF23GUlPk1xKTo/fBI7CCs6He
> j4SZTVSmK8Theo3m3HBR3AqHWyA7a8ehqijMDUza9OO/ED2gY29crV9gqm7nR///
> AaR4gNeEa+2I/ymyDyEJvQIDyWRpZFavkS2AXnu/IcHtxlJO96BIQsikdeNnI39E
> P4slRzWSvpnmTNABbCecPPaLmZSkhZMJKwuHKo4YAQsVCBRjlj3DlE5zGAhRV4xj
> jan4lhJjRDtvZHWXCOiGTxvnYtwl5uYjbef0XGeXz44AwoLWxxkRb1k7FmG2wJB+
> dNrRh8SXOy/FnWtFaQjapksfbO8szMohV7nVIHB+InmLSeab/Ifs+azDiuMwdWEl
> 8iGkZPMn3AfbH593kD5oTy4qgBm+k+sUJ+/RmU7bLxu3JCDuuRce0U9cXHn7/12o
> BnfspJY7vq6iSSD282RCknjcsS0uy2pQfeHED+S6KIS/bw4mGAQXTj2acp07MIol
> pfes+scjVo+SJTRZiGLABpX+0VJgSaZI1OhWTVFWe8zQhCghXN+91/xT0XIQvNrH
> p0MoP6H4qRrfhdHFdPEB
> =ZLFO
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
--gibu
Re: tomcat dB persistant session store delay
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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?
> 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.
Can you post your existing configuration?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXtdiCAAoJEBzwKT+lPKRYkfEP/1KK1BNjDbE20L9pBS9i5NTV
B2A7IxN0F7D14QmBVgEe1RO3uB+e2XyS6up4S2VOW1g+YMUj2p2VoBjs6zfiIeQX
VlRkFbz9zyrHwhliR7BrM9fI510a9Tzq+upML1uwF23GUlPk1xKTo/fBI7CCs6He
j4SZTVSmK8Theo3m3HBR3AqHWyA7a8ehqijMDUza9OO/ED2gY29crV9gqm7nR///
AaR4gNeEa+2I/ymyDyEJvQIDyWRpZFavkS2AXnu/IcHtxlJO96BIQsikdeNnI39E
P4slRzWSvpnmTNABbCecPPaLmZSkhZMJKwuHKo4YAQsVCBRjlj3DlE5zGAhRV4xj
jan4lhJjRDtvZHWXCOiGTxvnYtwl5uYjbef0XGeXz44AwoLWxxkRb1k7FmG2wJB+
dNrRh8SXOy/FnWtFaQjapksfbO8szMohV7nVIHB+InmLSeab/Ifs+azDiuMwdWEl
8iGkZPMn3AfbH593kD5oTy4qgBm+k+sUJ+/RmU7bLxu3JCDuuRce0U9cXHn7/12o
BnfspJY7vq6iSSD282RCknjcsS0uy2pQfeHED+S6KIS/bw4mGAQXTj2acp07MIol
pfes+scjVo+SJTRZiGLABpX+0VJgSaZI1OhWTVFWe8zQhCghXN+91/xT0XIQvNrH
p0MoP6H4qRrfhdHFdPEB
=ZLFO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org