Hi Doal
Thanks for trying these tests out. Much appreciated.
I have some comments below.
On 5/7/10 11:53 AM, glassfish_at_javadesktop.org wrote:
> I tried a few things and this is what I found. I did try adding a third node (using a virtual machine) and I still see the issue so I removed it.
>
Good to know that this is not the same as the specific issue we were
seeing with 2 node clusters before 2.1.1 release.
> Using my existing domain, node-agents, virtual machine, Apache mod proxy, etc., I switched to a "file" realm from my JDBC realm (still using my current application), and I still see the issue.
>
I am not sure I understand how this is related to replication/resumption
of sessions or reasons why you thought the realm had to do something
with this.
> I then undeployed my application and deployed the clusterjsp.ear. I refreshed the page many times using the refresh in Firefox and using the refresh button on the jsp, and the session stayed the same.
Good. Worked as designed up to now :-)
> I did this for several minutes and was pretty much giving up. Then as I was writing this I tried it again and after a little while I saw the session ID change.
It is possible that your session expired and hence a new one was created
at this point.
> I went on refreshing for several minutes trying to make it happen again. Then I tried refreshing as fast as I could and still didn't see it happen again. Then I simply held down the F5 key to have the "key repeat" send as fast as possible, and I saw the problem. I then restarted all the glassfish parts, just for grins and got it to demonstrate the problem again by holding down the refresh key F5.
>
If your intention is to see if replication works under load and multiple
concurrent requests, then you should ideally use a load generation
script or tool such as Faban - pressing F5 continuously is really not a
good substitute to see real world working of replication under load and
concurrent requests. Pressing F5 continuously can lead to partial
information, including session id and request version information not to
be sent to the server, as your request may have been truncated by the
browser's refresh function ( this could vary with different browsers)
pressed in a way that will border on ensuring partial headers get sent
each time for the same session. At times, the session id and version
cookie would get sent and intermittently cut out. As a result, you will
intermittently see session information being lost on the Web Container
so it cannot locate the session or the version of the request within the
session scope. So you see the new session being created.
> I'm still using Apache mod proxy, and a Virtual machine but I don't really think those are the issue.
I'd suggest to not rule these out without a patient step-by-step
exercise time permitting. As before, I would suggest that you begin
with what we state to be supported configuration i.e our LB plugin with
a supported Web Server, physical machines, and clusterjsp app, and then
move up to your app, to see at what point does this problem manifest.
The F5 test based loss of session is very different from the occassional
loss of session that you were seeing with your app when you originally
posted here.
OTOH, if you don't see any problems with the supported artifacts
mentioned above that would give you an indication to suspect the
mod_proxy tier or the virtual machines.
> I can use another physical machine pretty easy so I'll try that also, but I think you might be able to create the same issue in your environment by sending the refreshes as quickly as possible.
>
Hope my explanation above on the F5 based approach is helpful here. We
do not rely on the refresh based approach as a substitute for load based
testing driven by a load running tool.
> My application is fairly good size and does use frames and creates many server hits for each page transition so this does make some sense from that point of view. Let me know what you think and if you have any suggestions with configuration or anything. Thanks for your help.
>
For apps with UI having frames, or widgets making ajax based calls
within the session scope, such that these alter the sessions
concurrently from different parts of the page - this can throw off the
mechanism we have for versioning of requests within a session's scope
that we use to ensure the latest updated session is returned to the
user. Under such circumstances, we recommend adding a property called
relaxCacheVersionSemantics to your sun-web.xml
I am adding a snippet for your convenience.
<sun-web-app>
<session-config>
<session-manager persistence-type="replicated">
<manager-properties>
*<property name="relaxCacheVersionSemantics" value="true"/>*
</manager-properties>
</session-manager>
</session-config>
.....
</sun-web-app>
This will hopefully help you cut to the chase with respect to the
problem but I would still recommend the step-by-step approach I have
suggested above.
Hope you are able to succeed with the above suggestions. Let us know how
it goes.
Cheers
Shreedhar
> [Message sent by forum member 'doal']
>
> http://forums.java.net/jive/thread.jspa?messageID=468915
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>