The case of null httpcontext.current.session

Because of un-addressable client in SL, we introduced Polling Duplex channel to support callback in WCF Silverlight. It started as a channel in Silverlight2. We added service model support in Silverlight3 and MultipeMode, aka chunking in Silverlight4. See MSDN for more information about how to use it.

Recently some customer reported that session state object in httpcontext.current is null in server side while using PollingDuplex binding (https://forums.silverlight.net/forums/p/97983/270263.aspx). As usual, customer’s request is our requirement so we set off to investigate this issue right away.

First we need to have a little bit contexts on the Polling Duplex protocol. As shown in below diagram, a message from client to server is sent using short lived HTTP request. As soon as server receives the message, the original message is returned with empty HTTP response. After that, client will issue a long poll HTTP request and server will hold that request and use it to send any callback messages.

 

To understand why session state is null, I set a couple of break points in our polling duplex channel stack. One at the place where we receive client message, one at user’s server code. Using these two break points, I confirmed that we have a usable session state object in httpcontext.Current when we first received message from underlining channel, however when the user code is invoked for that same message it became null. So it is some action we did in the middle caused disappearing of the session state. To nail it down I stepped through the code after getting the first client message and checked the session state value along the way. It didn’t take me long. As you can see from above diagram, after we receive the message, we would reply with an empty HTTP response right away. It turns out this reply destroyed session state. I also further verified same issue with OneWay operation of WCF since we also do the same reply in that case.

Following up with our ASP.NET guru Thomas Marquardt explains why this happens.

You can only access HttpContext (and hence Session) during your ASP.NET pipeline event, furthermore, session is only available between the acquire session state and release session state events.

So now we don’t have much choice but advice against using session state with Polling Duplex. User will have to use their own state management mechanism.

 Hope this helps

Joe Zhou

WCF RIA Base team