tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Help with Tomcat 7 clustering using BIO receiver
Date Thu, 03 Jul 2014 21:51:15 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 7/3/14, 2:19 PM, Mark Eggers wrote:
> João,
> 
> This list has a convention of posting either inline or at the end
> of the message you're replying to.
> 
> See here for mailing list notes:
> 
> http://tomcat.apache.org/lists.html#tomcat-users
> 
> On 7/3/2014 10:24 AM, João Sávio wrote:
>> Hello
> 
>> Some points below:
> 
>> ** What is "on time"?* In my application, a group of users should
>>  always hit the same node after the first request. So, in first 
>> request each group of users will receive an specific cookie, and 
>> LB will perform the load balancing based on this cookie. In first
>>  request, a user can hit any node, but from the second, he or she
>>  should hit the same node.
> 
> Hmm, so 'on time' really means that subsequent requests should hit
> the same server.
> 
> If you're using sessions, Tomcat has an attribute on the Engine 
> element called jvmRoute. So depending on your load balancer (and
> if you use AJP), you can use Tomcat and AJP to route traffic. In
> that case, there's no need to write a special cookie.
> 
> At any rate, this doesn't sound like a clustering error per se.


I wonder if the real problem is a race condition: the cluster can't
replicate fast enough to stabilize before the second request comes in,
plus the lb configuration might not be correct.

João, can you confirm that request #1 and #2 are definitely hitting
the same Tomcat instance?

If you connect to TomcatA, set a session attribute, then reconnect to
TomcatA and get that session attribute, then it should be the same
unless something is awfully wrong. You don't even need to have
clustering enabled to test the above.

However if you hit TomcatA, set a session attribute, then connect to
TomcatB and try to get that session attribute, your request may have
arrived too early for the cluster to have pushed-out the session
attribute change.

So, if you can prove that both requests have gone to TomcatA and you
are getting "errors", then there are several possibilities:

1. Tomcat has a huge bug and no web applications would work worldwide.
2. You are mishandling the "setting" of the session attribute
3. You are wrong about which server the client is hitting

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTtdBTAAoJEBzwKT+lPKRYtiwP/1dW2qplyepTgDTNixNw0viZ
29XFywsYAmDdMxzWcgkcl7Nrw3kVUcJVf+jLpxNCUxRJq7z4+zuyOLkImn2XW4a+
ygG1op69FSwsVEfQyHIH8OVjdYDUj6WPpP8bu2KbbkR0jtAiHO569+869WOvPyuA
z+oBhBhWB5w7e41qmQnLr6y3+hU19hGuayxkR61tqmZCPp6kpwRH2yN3IbhId2In
8DLoR5z6077jxPeXR6o3goB6Y9LbrPoYFUwdfQTpzrF8AvQ2wDl/CRuM2n9wB/ez
Oclnz0bw4JNegtarEJeiu4G1Qqf7WCqhVv4a8GfWYtr0ISk8GBBcCRjYZcoyU5IU
hSnNBGn586AhZ3BK5t1ySwrC6RiKH6MIR8fdBOSw1eZnTycPBSK6avZ4E8ahQDIp
uA93W+cME58gtmzdl2q7iLjRbwGdgebw++yfR4G42Tb4rUYsmOzsCPGx/nIqxB5E
FBea8xGwb802rFpYMxgMp8SzRy078RrDx2aptNfrb5oP9YeQ/pGrX9tVVtTlxNTk
8DKA8GHL4fiONAJB48iD2sTSv4jAhFInHnF4ykl0zjN7t3f0phMmSExeoH7HbFUI
G589M4KAs5X00xCSFt9gXdU+tpuFL+/x6kBAGrNmT5IySIvm+BfxTXjvg2daAjcC
+FAocYeosZumP5g2tICv
=1Si4
-----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