Hi all,
I have searched this forum and found a lot of good information from Alex Glosband and others about the infamous "Detected duplicate HTTP - based FlexSessions, generally due to the remote host disabling session cookies. Session coolkies must be enable to manage the client connection correctly." message.
It seems, however, none of the cases are identical to ours. This is ours:
- Resin 3.1.9
- Oracle Coherence 3.7.1 with Coherence*Web (session replication)
With this setup we get the "Detected duplicate HTTP..." message on the first attempt to use BlazeDS and on every subsequent call. The same client and server code works fine in a local sessions setup. With Coherence 3.3 (currently our production environment) it seems to occur less frequently, but still as frequent as it is a major issue for us. It fails even with a single node using in-process distributed caching in our test setup (as well as with multi node out of process caching in our staging environment, for Coherence knowledgeable the resin app server runs with tangosol.coherence.session.localstorage=true in the first case and false in the second).
Both the listener and message broker are mapped as "Coherence aware" in web.xml[1] so that they should use clustered sessions.
We have been digging a bit and we found out that if we commented out lines 427 and 434 of flex.messaging.endpoints.BaseHTTPEndpoint from version 4.0.0.14931 it seems to mask the bug. We added some logging in the setupFlexClient method and it seems that we get more or less a new FlexSession for each and every call - but they have the same cookie and thus underlying HttpSession. I.e. the list returned from flexClient.getFlexSessions() keeps growing. Thus we are not so keen on going to production with that memory leak and the above mentioned ugly hack of commenting out the detection of duplicates.
We use request scope for the remote object, but could in theory use any scope as we do not really have any state on the object itself, it is all HttpSession state and return values that are key (logon is performed prior to doing the first blaze call, in pure forms and ajax, and it is not a timing issue in that regard we are seeing).
Hope someone can shed some light on what can be happening. Is there any "reference testing"[2] or something when the FlexSessions are created that makes them being created as new? Where are they created? We do not know the inner workings of the BlazeDS source, we just watched the call trace of the unwanted invalidation and found that to be line 427 of flex.messaging.endpoints.BaseHTTPEndpoint.
Can we disable FlexSessions? Since the flex and plain html parts of the app share the sessions, we always use FlexContext.getHttpRequest().getSession() anyway, never storing any state directly in the FlexSession or on the remote object. Or maybe there is a config option to help us with this detection (or creation) of multiple FlexSessions?
Cheers and TIA,
-S-
[1] - For instance, this i the message broker servlet def:
<servlet>
<servlet-name>MessageBrokerServlet</servlet-name>
<display-name>MessageBrokerServlet</display-name>
<servlet-class>com.tangosol.coherence.servlet.api22.ServletWrapper</servlet-class>
<init-param>
<param-name>coherence-servlet-class</param-name>
<param-value>flex.messaging.MessageBrokerServlet</param-value>
</init-param>
<init-param>
<param-name>services.configuration.file</param-name>
<param-value>/WEB-INF/flex/services-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
[2] - As you undertstand this is speculation based on pure air, but it could be that in Coherence there was a serialization/deserialization happening somehow that would break such a test?
