Avoiding duplicate session detected errors in LCDS (and BlazeDS)

There are a number of situations where you might have more than one FlexClient in a LCDS application. For example, if you loaded two LCDS apps into a parent application as sub apps, each LCDS app would have its own FlexClient.

Note: The FlexClient represents the LCDS application on the server.

For the LCDS sub apps to work correctly they must each be able to maintain session with the server. LCDS runs in a JEE application container and leverages this container for things like security (authentication/authorization) and session handling. Currently the client application is responsible for ensuring that each FlexClient can maintain session with the server. Failing to do this will result in duplicate session detected errors like the following.

Detected duplicate HTTP-based FlexSessions, generally due to the remote host disabling session cookies. Session cookies must be enabled to manage the client connection correctly.

In our example of two LCDS sub apps running in a parent application, if both sub apps load at the same time and simultaneously make requests to the server without a session already established on the server for the client application here is what happens. . . The server will receive ping requests from both sub apps. Neither ping request will have a session cookie header as there is no session cookie currently stored for the client application by the browser (or AIR runtime). The server will create a new session for each request and also create FlexClients for each request and tie these FlexClients to their respective sessions.

Note: The client ping requests will have a DSID of nil which tells the server that a new FlexClient needs to be created.

The replies for each of these requests will be returned to the client. When the browser (or other client runtime such as AIR) receives the first response it will store the session cookie set by the set cookie header.

Note: If one of the HTTP endpoints is being used, the session cookie is the standard JSESSIONID cookie used by JEE application containers. If one of the NIO HTTP endpoints is being used, this by default is the AMFSessionID cookie. The session cookie name for NIO HTTP endpoints can be changed in your services-config.xml file.

When the browser receives the second response, it will overwrite the first session cookie with the new session cookie on this response. Both session cookies have the same path element so only one will get stored by the browser. Each sub app will store the DSID (the FlexClient id) included in the reply message it received from the server.

The client is now in a bad state because on the server the first FlexClient is associated with a session that the browser no longer knows about. If the first FlexClient makes another request to the server, the request will have the session cookie header for the second FlexClient and the server will throw a duplicate session detected error. This is because it correctly believes that the FlexClient it received the request from was already associated with a different session on the server.

For the client application to make sure that FlexClients in the application don’t get into this bad state, the client application must make sure that a session is already established on the server before multiple FlexClients connect to the server at the same time.  

There are a number of ways you could implement this. If a browser is being used to run the application and not AIR, you could call a jsp page to load the application. The jsp page could both create a session for the client application and return an html wrapper to the client which would load the swf. If the application will be run in AIR as well, the parent application could call a jsp page or servlet that would create a session for the client application and then the parent application could load the sub apps. The parent application could also call a Remoting destination which would automatically create a session for the client application on the server but would also create an additional FlexClient which you may not want.

It would be nice if there was a way to resolve this in LCDS and not make application developers have to think about it. The flexibility of LCDS makes it difficult to provide a solution that works for everyone though. LCDS sub apps loaded with SWFLoader run independently of each other. To make this work LCDS would have to provide its own components for loading and managing sub apps which definitely seems like overkill. Neither JEE nor most browsers appear to provide a clean way to have more than one session per client application. For the NIO HTTP endpoints where we provide our own session implementation, it may be possible to implement a solution where the session cookie name would be unique for each FlexClient. Rather than using a common session cookie name such as AMFSESSIONID, we could possibly make the session cookie name a combination of the common name and a unique identifier such as the session id or FlexClient id which would prevent the browser from overwriting these cookies if the path element on the set cookie header was the same. For now though, you’ll have to use one of the workarounds I’ve suggested or come up with your own. Just make sure that all FlexClient instances in your application share a single session on the server.

About aglosband

I am a Quality Engineer at Adobe Systems working on the BlazeDS and LiveCycle Data Services products. I know a little bit about some things and more than a little about other things having to do with Adobe technologies and products such as BlazeDS, LCDS, Flex, and the Flash player. I have also spent a lot of time maintaining build and test automation systems, developing test frameworks and performing load and scalability testing. I'm hoping to share some of my knowledges and experiences in these areas with anyone who might also be interested in such *boring* stuff.
This entry was posted in BlazeDS, LCDS. Bookmark the permalink.

12 Responses to Avoiding duplicate session detected errors in LCDS (and BlazeDS)

  1. pratyoosh says:

    Netconnection in the flash player batches the AMF request for the same endpoint.
    So validate the understanding that this problem can potentially be avoided by making sure that for a web application on the server there is a single endpoint url thereby multiple simultaneous calls will be batched & the contention can be avoided, also for multiple sub applications the RemoteObject can be shared so the endpoint ping happens just once.

  2. aglosband says:

    Hi. That’s pretty much correct. If the client has a single connection to the server then you won’t have this problem. This has less to do with the server though as you could have a single endpoint url on the server and still have the client make two ping requests to the endpoint at roughly the same time. That would cause a session on the server to get created for each request.

    As long as the BlazeDS/LCDS components in your application share the same ChannelSet then you won’t have this problem because the components will share a connection to the server. If you needed the components in your application to use different channels, say one secure channel for sending data to the server (say a stock trade) and a non-secure channel for receiving updates pushed from the server (say stock ticker updates) you would need to be careful to avoid the duplicate session detected issue.

    If you wrote the application in such a way that the sub applications shared the same RemoteObject or even just shared the same ChannelSet then yes, you would avoid this issue. Because of the way classloading works in the FlashPlayer though, you might need to have all of your BlazeDS/LCDS components (RemoteObjects, ChannelSets, etc.) defined in the parent application.

  3. Tahir Awan says:

    Hi.
    I am getting this error only in a Production env. so most probably it is due to cluster. But only 2 out of ~100 users are getting this error. 1 of the user can run fine if he uses Firefox.
    I will try the fix from http://martinzoldano.blogspot.com/2009/04/appengine-adobe-blazeds-fix.html

  4. Ellis Willis says:

    This is actually a nice point you have created. I am certainly looking forward to give it a go personally and look at if I find the exact same results.

  5. aglosband says:

    Hi Tahir. The problem with that fix you point to is that it completely disables duplicate session detection. This may not cause problems in your application but it could cause problems in any applications that need to maintain state between the client and the server.

  6. Mothers says:

    Cool post. I really like your idea and i think it would be useful for my projects.

  7. Ryan H says:

    We are trying to get to the bottom of this “duplicate HTTP-based FlexSessions” error. As we’ve been moving from CF8 to CF9 all of our tests worked well until we tried using a CF 9 server with two instances (with round robbin). Now our Flex app won’t work at all.

    With two instances, this error shows up very often, it even prevents our app from loading, anywhere from 3-5 calls seem to work, and then we will see this message.

    This wasn’t a problem with CF8 and LCDS Express 2.6.1, is this error new with a particular version of BlazeDS/LCDS?

  8. Good Forex says:

    cool, Really good sharing this. ;-)

  9. flx says:

    HI Alex,
    I tried first approach but It does not work for me . I made generated html as jsp with page directive having session = true.

    Am I missing anything ?

    Thx

  10. Ryan H says:

    We were able successfully recompile BlazeDS 3.2 with session checking off, and our app is now working as it did with CF8 (or at least it seems to be working).

    I have also spent a lot of time working with Adobe Support to get the issue identified as a bug, hopefully it will be addressed in a future release of BlazeDS.

  11. Pingback: Duplicate session errors in LCDS/BlazeDS « My Journey

  12. Pingback: Duplication session error « Lin's Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>