It also just occurred to me that we have another problem that is probably related (or in fact a result of the same root cause). To track user log in we simply place their id into a variable in the $_SESSION variable. If there is an ID in the session, that is the logged in user, otherwise, the person isn't logged in. To log them out, we simple delete this value. This fails randomly about 10% of the time (much more commonly than the other bug being discussed here).

So, the original bug seems to be related to inserting something into a clustered session. The second bug is related to deleteting something from a clustered session. It seems likely that there is some synchronization/race condition between the servers that is resulting in the server with outdated information occasionally "winning" and its incorrect information to persist instead of the correct updated information.


Andrew Fritz wrote:
We are using cluster store assuming I've understood the config file/documentation.

I'm sure that roll over isn't the problem. I've never seen a case were an active session moved from one server to the other UNLESS I shut down a server so I'm sure our load balancer is leaving them where they are unless that server goes down. I've also verified that the clustering is working as designed by taking a server off line and continuing the process on the remaining server. Doing so doesn't seem to cause this problem. We can not reliably reproduce this so it is hard to test. I know I have reproduced it without the session hopping servers.

Other relevant facts: Resin 3.1.3, using more or less the default config file...
>From the webapp-default section of the server config:
	<persistent-store type="cluster">
		<init path="session"/>


Scott Ferguson wrote:
On Mar 13, 2008, at 8:39 AM, Andrew Fritz wrote:

We have a 2 node cluster behind a commodity load balancer with sticky
sessions. We are using PHP for front end pages, but all of our  
objects are Java and are saved/loaded from our DB via Hibernate. We
store php variables and objects in the php $_SESSION and that works
great. We store java objects in the java session via the
$request->getSession() (which I assume is the same as the request
variable I would have available in a JSP page, or the  
parameter in a servlet).

More or less randomly, the session will drop a value (or perhaps not
store it to begin with). The scenario I am working with is this:

What kind of distributed sessions are you using?  cluster store?

Cluster store.
If you're just relying on sticky sessions, then you could see that  
issue if the load balancer decided to rollover to the other server for  
some reason.

-- Scott


A request to the start page for a multiform section of the site  
a blank object, populates it with some default values (based on how  
user entered the wizard), and places it in the java session:

$memory = new MemoryBO();
$session = $request->getSession(true);

and then serves up the first form (an AJAX search page). The user  
what they need and clicks the appropriate link which submits the form.
The page receiving the request attempts to get the blank object from  
session and populate it:

$session = $request->getSession(true);
$memory = $session->getAttribute("wizard.memory");
*** if (empty($memory)) return error status...

In about 1 out of 100 cases the if statement above flagged by "***"  
fire the return error statement. This happens randomly, and happens  
frequently after a restart or redeploy.

It should also be noted that we were originally putting the java  
in the $_SESSION variable. They always failed to serialize, (and thus
were lost on restart/deploy) but otherwise worked EXACTLY the same as
using the java session. The value mysteriously disappears.

I've dug through the logs with log level "fine". We can not reproduce
the bug at all on our non-clustered development environment.


resin-interest mailing list

resin-interest mailing list

_______________________________________________ resin-interest mailing list
resin-interest mailing list

Reply via email to