none
Cookies In WCF Client RRS feed

  • Question

  • Hello,

    I have a legacy WCF application I'm trying to port to Azure App Services.  The WCF Service uses WSHttpBinding with Message level security, so the problem I'm running into is that on Azure App Services we don't have sticky sessions that stay persistent to the same server.  

    During the SSL / Message negotiation Azure App services is sending back a cookie in the header called ARRAffinity which essentially routes it back to the same server and gives it persistence.  If my client can return that same cookie in every request after the first one, then it should balance properly.

    I'm using a SOAP WCF Service - does anyone know if this is possible?  

    Thanks.

    Saturday, March 5, 2016 1:46 AM

Answers

  • I have a legacy WCF application I'm trying to port to Azure App Services.  The WCF Service uses WSHttpBinding with Message level security, so the problem I'm running into is that on Azure App Services we don't have sticky sessions that stay persistent to the same server. 

    Yeah, I had the problem sticky sessions using ASP.NET solution where I worked on converting the solution to use ASP.NET Web forms, MVP, WCF Web service with BLL, DAL and EF ORM on the backend.

    The requirement was this.

    if the user never turned off the machine,  the browser was on a page in the solution, the user walked away for a week from the machine or the page timed out, the user came back to the machine back to the page left and did something to active the solution on the page, the solution had to put the user back into the session as if nothing happened and continue on from the last point left. :)

    I solved it by taking all Web server session information for the client, serialized all session objects,  on page unloads , spawned  an async theread and sent the information to Statetable to the database.

    After a session timeout, the page went active again and the Web form codebehind detected no session object, it knew how to take session user information that was hidden on the pages and go back to the database Statetable and get the user's session data, put the session information back into session like it was never lost.

    Also IIS resets were being done periodically right in the middle of the user session, and the application still knew how to recover back to the user's last known good session.

    So a sticky session can be done programmically.

     
    Saturday, March 5, 2016 3:05 AM
  • Thank you, yeah I think I figured out my issue, sort of similar with the way that WCF works on the client side.
    Monday, March 7, 2016 1:32 AM

All replies

  • I have a legacy WCF application I'm trying to port to Azure App Services.  The WCF Service uses WSHttpBinding with Message level security, so the problem I'm running into is that on Azure App Services we don't have sticky sessions that stay persistent to the same server. 

    Yeah, I had the problem sticky sessions using ASP.NET solution where I worked on converting the solution to use ASP.NET Web forms, MVP, WCF Web service with BLL, DAL and EF ORM on the backend.

    The requirement was this.

    if the user never turned off the machine,  the browser was on a page in the solution, the user walked away for a week from the machine or the page timed out, the user came back to the machine back to the page left and did something to active the solution on the page, the solution had to put the user back into the session as if nothing happened and continue on from the last point left. :)

    I solved it by taking all Web server session information for the client, serialized all session objects,  on page unloads , spawned  an async theread and sent the information to Statetable to the database.

    After a session timeout, the page went active again and the Web form codebehind detected no session object, it knew how to take session user information that was hidden on the pages and go back to the database Statetable and get the user's session data, put the session information back into session like it was never lost.

    Also IIS resets were being done periodically right in the middle of the user session, and the application still knew how to recover back to the user's last known good session.

    So a sticky session can be done programmically.

     
    Saturday, March 5, 2016 3:05 AM
  • Thank you, yeah I think I figured out my issue, sort of similar with the way that WCF works on the client side.
    Monday, March 7, 2016 1:32 AM
  • The key for me was the Web form/view was dumb it knew nothing and everything was controlled by MVP, its Presenter and the service layer.

    https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter

    http://polymorphicpodcast.com/shows/mv-patterns/

    Monday, March 7, 2016 3:16 AM