Flash client not cleaning up socket connections

Question

I have an embedded flex application which recieves asyncronous data updates from a Blaze DS server on Tomcat that is using spring integration. I'm currently using a single, unsecure channel just to make things simple.
My problem is that I'm periodically getting faults on the connection. This is happening far too often and it takes a considerable amount of time for it to succesfully reconnect. In investigating I've set up TCPMon to monitor the communications between the flex client and tomcat.
When my application initially starts I see an active AMF connection with my server and my client recieves messages normally. However, if I exit the screen, tcpmon shows that the connection is still active. It times out and closes the connection within a minute or so. Restarting the application by returning to the page opens a new connection normally.
The problem is that when I hit the refresh button on the page -- I.E. 7 -- the old connection doesn't go away, but the flex client attempts to create a new connection. Via TCPMon I see these requests and the server responds with the error:
    The request sent by the client was syntactically incorrect ().
This is error 400 from tomcat but with no detail. The flex client will attempt to reconnect several times in vain and eventually it will call my fault handler. Throughout the reconnect process, TCPMon shows the original connection still open. It eventually times out as described above and the application sits idle with no connection to the server. If I refresh again after the "leaked" connection has closed the application connects successfully.
Examining the failed requests vs. the successful requests I find that they are all using the same JSESSIONID which makes sense because the browser has not exited, just the flash player. I'm assuming that the server is giving a response of 400 because I'm trying to create a second connection with the same session ID. However, I have not been able to verify this.
Obviously, it would be nice if the server responded with some more detail on the rejected requests. However, it seems to me that the flash player ought to close it's sockets instead of leaving the wire-protocol to time out. On the server side, I have turned on trace logging and I see the request being processed, but I don't see any indication that the request fails. (errors, warnings, etc.) I have tried to close the socket from the client side using Consumer.unsubscribe(), Consumer.disconnect(), and ChannelSet.disconnectAll() to no avail. The socket remains open until the TCP timeout. I have walked through the ChannelSet.disconnectAll() logic on the client side, but it is extremely complex and I have not found any code that closes a socket.
Has anyone else seen this behavior? Does anyone know of any workarounds for it? I hate to spend the time walking through code if someone has already found a solution.

Answer 1

This is clearly a problem with the StreamingAMFChannel in the I.E. flash player. Under firefox all this stuff works.
Apparently, it is taking a very long time for StreamingAMFChannel to initialize for some reason. The NetConnectionChannel is relying on the connected boolean to determine whether or not it should disconnect it's socket when it's told to disconnect. That's a bad idea. Until the streaming protocol has completed initialization it's not connected even though the NetConnectionChannel's socket is connected. The NetConnectionChannel should look at it's socket rather than relying on the Stream state.
The question now is why it takes so long to initialize but only with I.E.