stateserver 2 clustered boxes argh!

[sagey]

I have an asp.net 1.1 application that i cannot get to work on 2 clustered boxes
(wlbs)

Both boxes use a separate box as the stateserver (service not sql db) and when only one is in the cluster both boxes work fine (saving session data, reading it, doing what they should etc etc).
the problems start when both boxes are in the cluster, it seems when going between the boxes the session data cannot be read and the application throws an error (which is caught in the app, basically if the method can't read the session data it returns false and then the page displays a custom error page saying session has timed out).

I've googled a lot on this problem and found articles about making sure the validationkey is the same in both machine.configs (which i've done) i've also made sure the iis metabase is the same on both boxes, all to no avail.

I've been at a loss on what to do for ages so today i thought i'd write a simple test application that will sit on both boxes, in the cluster testsesh.aspx saves a string to the session, then redirects to readsesh.asp which response.writes the session to the screen so i can see if it can pass session state between boxes outside of our big app.

here is the code for testsesh.aspx

    Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        'Put user code to initialize the page here
        If IsPostBack Then

        Else

            Dim i As Integer
            'add something to the session
            Session.Add("testOne", ConfigurationSettings.AppSettings("message"))
            'just read out the contents of the session to make sure there is something in there
            Response.Write("<br />Contents of session on " & System.Environment.MachineName.ToUpper & "<br />")

            For i = 0 To Session.Count - 1
                Response.Write(Session.Item(i))
                i = i + 1
            Next
            Response.Write("<br />End of contents of session<br />")
        End If

    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim strRedirectPath As String
        strRedirectPath = ConfigurationSettings.AppSettings("pageone") & "readsesh.aspx"
        Response.Redirect(strRedirectPath)
    End Sub

here is the code for readshesh.aspx

   Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        'Put user code to initialize the page here
        Dim i As Int16

        Response.Write("Contents of session of " & System.Environment.MachineName.ToUpper & "<br />")
        For i = 0 To Session.Count - 1
            Response.Write(Session.Item(i))
            i = i + 1
        Next
        Response.Write("<br />End of contents of session<br />")

    End Sub

putting both boxes in the cluster i browse to testsesh.aspx. it adds the string from the config to the session. reads out the session. then on the button click redirects to readshesh.aspx

Unfortunately tho i can't get this to work. if i happen to browse to box A for testsesh.asp then when it redirects it still goes to box A for readshesh.aspx it never seems to go to box B.

Please, if anyone has any ideas what can be wrong or what i need to do to sort this out i would be really grateful as this is a complete pain in the arse.

[venerable bede]

Have you considered using SQL Server to retain session state ?
I am convinced that would solve your problems......if you are using sql that is.

[sagey]

thanks for the reply bede.

unfortunately storing the session on sql server is not an option i'm afraid. we do have access to a sql server 2000 server (the web app uses it) but its got enough load on it without us adding more laod with storing the session on it.
(which is why we went the state server route in the first place).

If anyone can suggest anything i'd be grateful as altho the web app does run ok(ish) on one webserver it'd be nice to have it on 2.

[venerable bede]

You're in a bit of a pickle.
The only way I can figure out how to get this to work is to perform a hack.
You need to have some central storage of session data which can be accessed from both clusters.
Maybe you could write this info to an xml file when moving between boxes.

It's not perfect I know but I think MS recommend you use sql server in this sort of situation.

It's an interesting problem and would be keen to see how it can be overcome.

I'll nose about because I have a feeling I will have a similar problem soon.

[venerable bede]

When the user moves between boxes you could write all their session data to an xml file which maybe has their ID in the file name (or you could add an entry with their ID as an identifier) , then pass their ID in a querystring to the next box.

When that page is being processed you could open the file, grab the session data and shove that into session state on the new box.

[sagey]

thanks for the reply.

using a the asp.net state service is a valid way of storing session data in a clustred environment. there should be no need to go down the route you suggested.

[venerable bede]

If you do manage to solve the problem then please update this post.

I would be very interested in you're solution.

[Lord_Rat]

I suspect the sole cause of all your headache is that each box is using a different machine identity.

That said, for failover systems, you do have to use the SQL Server Session config route if you want to use Sessions. For that reason, you may consider using viewstate instead, which gets sent to the client, and not stored on the server, unless you are talking about a lot of data. (View state can slow the client down if there is a lot of data).

Anway, see this article for more info:
http://www.eggheadcafe.com/articles/20021016.asp

[sagey]

cheers for the reply lord_rat.

yep i've already read that article (among many others :^( ).
As i said i've added the validationkey in the machine.config and the web.config, the metabase is the same for both machines. so i'm really stuck as to what could be the problem.