Chris,
On 1/12/15, 11:36 AM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Peter,
>
>On 1/12/15 2:28 PM, Peter Rifel wrote:
>> Chris,
>>
>> On 1/12/15, 11:08 AM, "Christopher Schultz"
>> <ch...@christopherschultz.net> wrote:
>>
>> Peter,
>>
>> On 1/12/15 12:51 PM, Peter Rifel wrote:
>>>>> I'm running Tomcat 8.0.15 with Java 1.8.0_25 on Ubuntu 14.04.
>>>>> We have 5 instances that are all setup with session
>>>>> clustering as follows:
>>>>>
>>>>> <Cluster
>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>>>>> <Manager
>>>>> className="org.apache.catalina.ha.session.DeltaManager"
>>>>> stateTransferTimeout="5" /> <Channel
>>>>> className="org.apache.catalina.tribes.group.GroupChannel">
>>>>> <Membership
>>>>> className="org.apache.catalina.tribes.membership.McastService"
>>>>>
>>>>>
>address="${multicast}" /> </Channel> </Cluster>
>>>>>
>>>>> -Dmulticast=228.0.0.4
>>>>>
>>>>> To help prevent accidental misconfigurations that have
>>>>> occurred in the past, I decided to implement monitoring on
>>>>> the session replication by checking the JMX mbean
>>>>> Catalina/Manager/<host>/<context>/activeSessions attribute.
>>>>> Most of the time the values for the 5 instances are all
>>>>> within 1 or 2 of each other. Over the weekend we consistently
>>>>> had one instance that had more sessions than the other 4. It
>>>>> began with 102 sessions where every other instance had 95.
>>>>> Over the next 36 hours as more sessions were expiring over
>>>>> the weekend, the difference grew to 49 vs 29. Eventually it
>>>>> resynced and now they all report the same active session
>>>>> count. My question is, does anyone know why this would
>>>>> happen, and if this can be expected is there a better way to
>>>>> monitor session replication to ensure that there isn't one
>>>>> instance that isn't being replicated to? I believe this only
>>>>> happens on weekends when most sessions are expiring and very
>>>>> few are being created but I may be wrong.
>>
>> How is your load-balancer configured to distribute traffic?
>>
>>> Two of the instances are behind one load balancer, and the other
>>> 3 are behind another. They each provide a different service but
>>> are running the same war application and we want sessions
>>> clustered across both services. Each load balancer's initial
>>> distribution is based on the least number of connections, with
>>> persistence based on source IP.
>
>So basically all requests are randomly sent to back-end nodes? Or are
>you using session stickiness or anything like that?
Sorry, I should have clarified. Stickiness is based on the source ip, so
requests from the same IP will be routed to the same instance. With these
applications we don't expect sessions to change Ips very often if at all,
but if you think it would help I could stick based on the JSESSIONID
cookie.
>
>- -chris
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJUtCIvAAoJEBzwKT+lPKRYlOcP/38OxDsUWtGxtNVGqzsxXyyq
>UD4E+4zwVV/z9982YLG5kWF4NM/Ba/3pp69slIBRHGkoJa6wH8Lt7/cJEqIYqXpU
>+dlM4RHYsGO+7ZngMv0MQjG5oBtYdK7ratKDB5F3NpL+hJki4z/lzAofiyFHdq8n
>IVKbgi/aLCvD3FisoaPWf8dbksVVaw63ZNpP9tP8hW9fB5P0CXxUvvTV7A3x9FlE
>Em6aO/QegkNYNqPVv4AanCAr/Z35riwdhJ9NkglViBu7FB+mieCn2K+L4pL7T34P
>acr0Py8wNkDH56k90Ld8p2tzevo2HCoQpksZwg7OS3q1IhLd7AhUYSjQlAXpKfls
>9Ar9L/R7RNM9QmhdFMnmcR46CGsiWEGk+8ZdKMV55QvORTpDvYaITa5cWHFn247V
>p7U01kMo0jCmdq21h97u3KhMOvnKzARBormlmu2KudE2qv6fQ+qIif3zffTH5g/z
>7DXkAKC2KkqYrliJBmARzQHd1xkHBEQNOeYjUpsM92ETh5u4uQ+/JxNdcUh3U5fz
>BhtBWdFgxh2OGdkHgTabRJEaF5QJwBxTRO8sX5qXCBt69MFxQT19WXYnC4nGAcqz
>t9B2juEeKmloeCLzlvCOvbNbXW6uNFwWHgOJD4MggW4FqGN8Pcls29rBdU+8AuMx
>3hXL4h8eXuh5xLXxVnMq
>=A4nQ
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
