Avoiding duplicate session detected errors in LCDS (and BlazeDS)

使用BlazeDS的方式集成Spring、Flex，当Flex客户端创建AMFChannel对象用于交互时，Flex端出现错误：Channel.Ping.Failed error 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.

        经验证，IE、Firefox、Chrome均报错，看来跟浏览器无关。

        检查发现浏览器Cookies均未禁用，故与浏览器Cookies策略无关。

        验证发现，只有Flex客户端第一次访问时，才报此错误，之后访问都没问题。

        Google一下可知，原因是

        当第一个请求到达Sever端时，Server端的session会初始化，而在此session的初始化完成之前，FlexClient端有多个请求同时访问此Sever端的地址。

       3. The flex app makes two subsequent requests to the server before a session is established on the server for the first request.

From:   Duplication session error

We have heard a number of customers who run into duplicate sessions error in LCDS/BlazeDS. To understand why and how it could happen, please see explanationhere.

Basically, here are the causes and solution:
1. Cookies are disabled on the client.
solution: turn the cookies on the client.

2. Citrix had a policy to block session cookies.
solution: if you are using Citrix, need to turned it off.

3. The flex app makes two subsequent requests to the server before a session is established on the server for the first request.
solution: there are two options (See details here.):
a). the flex app should make the initial request and waits for its response (so a session is established) before making new requests.
b). trap the duplicate session error on the client and reissue the request. (See detailshere.)

4. Load balance tool cause subsequent requests to send to different server.
LCDS is a stateful server. This means that when a client makes an initial request to a server, the environment needs to make sure that all the requests from that client ends up on the same server from then on. In this case, you have to make sure your Load balance is configured so that all the subsequent requests from the same client is going to the same server. fail to do so will end up with this duplicate session error.
solution:: Make sure all the subsequent requests from a client end up at the same server.

Note, Some users may want to disable the duplicate session detection to get round the problem. Disabling the duplicate session detection is not an option because it’s a security risk. A single FlexClient is supposed to be associated with a single HTTP based session. If this is not enforced, your app could have some security risk. So, LCDS is checking the duplicate session for you and it should not be ignored. You should always find out and fix the underline problem instead of try to disable the duplicate session detection.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

From: 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 ofnilwhich 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.

------------------------------------------------------------

From: http://stackoverflow.com/questions/6614298/duplicate-flex-sessions-with-cross-domain-requests