WebService consumer in .NET; synchronous calls and client timeouts...

[intrepid_dw]

All:

I have prepared a .NET 1.1 client application that consumes a remote,
public web service. All the functions work as expected, and, in
general, the application has been successful for my purposes.

I have discovered one bit of behavior that surprises me, however. At
certain times, under heavy server-side loads, my calls to certain web
service methods will time out on the *client* side (proxy timeout). My
assumption was that the client timeout would abort any pending
server-side call; however, I'm seeing evidence to suggest that the
server call eventually completes (much later), but worse causes the
client application to begin shift processing to the point immediately
after the call was made. At a minimum, this is unexpected (and
presumably not thread-safe) behavior.

Now, this seems to me to be turning what I'm expecting to be
*synchronous* calls into *asynchronous* calls, which is not what I
expect at all (and may be a deficiency of my own understanding). The
webservice design forces me to make certain calls in a specific order,
but if this async behavior is correct (and my expectations are wrong),
my assumptions about the integrity of my "call sequence" are faulty.

Should web service method calls that timeout through the client proxy
persist on the server side to completion? If so, upon completion,
should they unceremoniously shift execution to the point in the code
where the webservice call originated? That may be what its supposed to
do, but I also thought that's what the async BeginXXX/EndXXX calls were
supposed to be for, and that's not what I'm using.

Appreciate any feedback,

-intrepid

[John Saunders]

<in*********@hotmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...

All:

I have prepared a .NET 1.1 client application that consumes a remote,
public web service. All the functions work as expected, and, in
general, the application has been successful for my purposes.

I have discovered one bit of behavior that surprises me, however. At
certain times, under heavy server-side loads, my calls to certain web
service methods will time out on the *client* side (proxy timeout). My
assumption was that the client timeout would abort any pending
server-side call; however, I'm seeing evidence to suggest that the
server call eventually completes (much later), but worse causes the
client application to begin shift processing to the point immediately
after the call was made. At a minimum, this is unexpected (and
presumably not thread-safe) behavior.

Now, this seems to me to be turning what I'm expecting to be
*synchronous* calls into *asynchronous* calls, which is not what I
expect at all (and may be a deficiency of my own understanding). The
webservice design forces me to make certain calls in a specific order,
but if this async behavior is correct (and my expectations are wrong),
my assumptions about the integrity of my "call sequence" are faulty.

Should web service method calls that timeout through the client proxy
persist on the server side to completion? If so, upon completion,
should they unceremoniously shift execution to the point in the code
where the webservice call originated? That may be what its supposed to
do, but I also thought that's what the async BeginXXX/EndXXX calls were
supposed to be for, and that's not what I'm using.

The web is stateless, even for web services. The server has no idea that the
client has timed out. In fact, there is no "abort service in progress"
method.
John