Web server cluster related problem

[Helge Kalnes]

We are running an ASP.NET application on a cluster of 3 web-servers, using
the Network Load Balancing feature of Application Center. We have
synchronized the machineKey in machine.config on the 3 web-servers, so we
can utilize a random algorithm for server selection for requests. The
application does not use either session state or application state.

We recently upgraded to .NET Framework 1.1 (including the hotfix for the
"doPostback bug"), and after that we experience a mysterious problem on our
production servers:

Let's call the servers A, B and C. Let's say you select a page (a GET
request), and it is served by either server A or B. The page contains a
form, so when you post it back and server C gets to handle the request, the
response appears to be like the original GET request. The page does not seem
to process the page as a POST request.

The same thing happens if the original page comes from server C, and the
postback is processed by server A or B.

Obviously, it seems that there is something wrong on server C.

We have checked everything we can think of. Among them the .NET Framework
installation, machine.config, and that the web application files are the
same.

Since this is a production environment, we are not allowed to use debug
tools. However, we have enabled tracing. When this problem occurs, we see
that
1) The form collection contains the posted data
2) That LoadViewState and ProcessPostData has been executed, both of which
are not executed on a GET request.
3) SessionId is unchanged

But even so, when the request is processed by the called page, it is
processed as a GET request.

Now I don't know where to keep on looking. Does it ring a bell for anyone?

Thanks,
Helge

[Tommy]

An ASP.NET webform detects if a request is a postback by comparing the
hash value in the viewstate of a page. This hash value is generated
by using a validation key. In the default setting, ASP.NET will
automatically generate an random validation key for each web server.
Thus, sending a POST request to a webform on a different web server
will not be recognized as a POST request because the validation key is
different.

Try changing the machine.config or web.config on each web server to
use a static validation key.

For example,

<machineKey validationKey="Some static key" validation="SHA1"/>

Tommy,

"Helge Kalnes" <he**********@electricfarm.no> wrote in message news:<ej**************@TK2MSFTNGP11.phx.gbl>...

We are running an ASP.NET application on a cluster of 3 web-servers, using
the Network Load Balancing feature of Application Center. We have
synchronized the machineKey in machine.config on the 3 web-servers, so we
can utilize a random algorithm for server selection for requests. The
application does not use either session state or application state.

We recently upgraded to .NET Framework 1.1 (including the hotfix for the
"doPostback bug"), and after that we experience a mysterious problem on our
production servers:

Let's call the servers A, B and C. Let's say you select a page (a GET
request), and it is served by either server A or B. The page contains a
form, so when you post it back and server C gets to handle the request, the
response appears to be like the original GET request. The page does not seem
to process the page as a POST request.

The same thing happens if the original page comes from server C, and the
postback is processed by server A or B.

Obviously, it seems that there is something wrong on server C.

We have checked everything we can think of. Among them the .NET Framework
installation, machine.config, and that the web application files are the
same.

Since this is a production environment, we are not allowed to use debug
tools. However, we have enabled tracing. When this problem occurs, we see
that
1) The form collection contains the posted data
2) That LoadViewState and ProcessPostData has been executed, both of which
are not executed on a GET request.
3) SessionId is unchanged

But even so, when the request is processed by the called page, it is
processed as a GET request.

Now I don't know where to keep on looking. Does it ring a bell for anyone?

Thanks,
Helge

[Helge Kalnes]

Thanx, but as you can see in my original message we have already done that.
If the machineKeys hadn't been synchronized we would have got an exception.
And in addition when switching between servers A and B there is no problem.
We have of course double checked the machineKeys several times.

I found a KB article
(http://support.microsoft.com/default...;EN-US;323744), but the
problem described here is related ASP.NET 1.0 and is supposed to be fixed in
1.1. I am not able to reproduce a problem as described in this article, but
it is of course possible that the problem is related to this.

:) Helge

"Tommy" <We**********@Hotmail.com> wrote in message
news:a8**************************@posting.google.c om...

An ASP.NET webform detects if a request is a postback by comparing the
hash value in the viewstate of a page. This hash value is generated
by using a validation key. In the default setting, ASP.NET will
automatically generate an random validation key for each web server.
Thus, sending a POST request to a webform on a different web server
will not be recognized as a POST request because the validation key is
different.

Try changing the machine.config or web.config on each web server to
use a static validation key.

For example,

<machineKey validationKey="Some static key" validation="SHA1"/>

Tommy,

"Helge Kalnes" <he**********@electricfarm.no> wrote in message

news:<ej**************@TK2MSFTNGP11.phx.gbl>...

We are running an ASP.NET application on a cluster of 3 web-servers, using the Network Load Balancing feature of Application Center. We have
synchronized the machineKey in machine.config on the 3 web-servers, so we can utilize a random algorithm for server selection for requests. The
application does not use either session state or application state.

We recently upgraded to .NET Framework 1.1 (including the hotfix for the
"doPostback bug"), and after that we experience a mysterious problem on our production servers:

Let's call the servers A, B and C. Let's say you select a page (a GET
request), and it is served by either server A or B. The page contains a
form, so when you post it back and server C gets to handle the request, the response appears to be like the original GET request. The page does not seem to process the page as a POST request.

The same thing happens if the original page comes from server C, and the
postback is processed by server A or B.

Obviously, it seems that there is something wrong on server C.

We have checked everything we can think of. Among them the .NET Framework installation, machine.config, and that the web application files are the
same.

Since this is a production environment, we are not allowed to use debug
tools. However, we have enabled tracing. When this problem occurs, we see that
1) The form collection contains the posted data
2) That LoadViewState and ProcessPostData has been executed, both of which are not executed on a GET request.
3) SessionId is unchanged

But even so, when the request is processed by the called page, it is
processed as a GET request.

Now I don't know where to keep on looking. Does it ring a bell for anyone?
Thanks,
Helge