A race condition could happen if you set replication to happen async. But I do have a memory of the configuration specifying synchronous replication, which would guarantee that the replication changes have happened before the request is complete.
On Thu, Jul 3, 2014 at 3:51 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
