Webmethod is sometimes executed twice after one request

[Ed Sonneveld]

Hi,

I have hosted my webservice at a hosting company and it has been working
fine for 2 years now. The webservice is called by winforms clients over the
internet, using the proxy class generated by visual studio.

What I do not understand, however, is that sometimes (say 1% of all calls)
are being executed twice on the server side. I notice that because each call
makes an entry in the database. This problem has been around as long as the
webservice exists.

I am sure the webservice is not called twice in the code of the winforms
client. The calling code is very staightforward.

It is important that the webmethods are not executed more than once after
one request, because there are some costs involved for the users of the
application.
Has someone seen this before? Does anyone have a hunch what might be causing
this? Configuration of the webservice, proxy class, IIS etc? Or is it
normal?

Thanks for any ideas.

Ed

[John Saunders]

"Ed Sonneveld" <es********@sunbase.nlwrote in message
news:44**********************@news.xs4all.nl...

Hi,

I have hosted my webservice at a hosting company and it has been working
fine for 2 years now. The webservice is called by winforms clients over
the internet, using the proxy class generated by visual studio.

What I do not understand, however, is that sometimes (say 1% of all calls)
are being executed twice on the server side. I notice that because each
call makes an entry in the database. This problem has been around as long
as the webservice exists.

I am sure the webservice is not called twice in the code of the winforms
client. The calling code is very staightforward.

It is important that the webmethods are not executed more than once after
one request, because there are some costs involved for the users of the
application.
Has someone seen this before? Does anyone have a hunch what might be
causing this? Configuration of the webservice, proxy class, IIS etc? Or is
it normal?

I don't see how this can happen without the client side actually issuing the
call twice. By "client side", I don't just mean the WinForms code, I'm
including any client-side network infrastructure, like proxies, etc. Perhaps
there's some sort of "smart proxy" which is outsmarting itself? I'd look at
a number of things:

1) Are the clients all running the same software and the same version of the
software?
2) Are the clients all behind the same network infrastructure, or are some
at different sites or different companies?
3) Is there any correlation between any subset of clients and the duplicate
messages, or is duplication evenly distributed across all clients? For
instance, maybe it's only the clients at one site which are having this
problem.
4) Network-wise, on a given connection, TCP/IP is meant to prevent the same
bytes being delivered twice. You say you're seeing a web service operation
called twice (ever more than twice, BTW?) This implies that the bytes making
up the call are being delivered more than once, which, if TCP/IP is working,
should not happen _on the same connection_. So, maybe something is
duplicating the connection and the bytes sent on it.
5) Are you ever getting any errors which suggest that only _some_ of the
bytes are being duplicated? I don't know if there are any ASP.NET counters
for this, but it would be interesting if the duplication is of part of a
message as opposed to being of an entire message.

Finally, if you can't solve this problem, or if it's not worth the time to
solve it, you could consider working around it. Have each client-side
request generate a GUID and a timestamp, and maybe some identifying
information about the client machine, and have them both sent with the
request. Record all in the database for debugging purposes, but use the GUID
to determine if the request is a duplicate. Unless the client-side is
issuing the request twice (fat fingers hitting a Submit button twice, for
instance), then you should be safe in ignoring (and flagging!) any request
with the same GUID as one already in the database. If your database code is
set up correctly, the absence of a given GUID in the database would be proof
that this is the original request; the presence would mean that it is a
duplicate and can be logged, and ignored.

I'd also throw an exception to get an error back to the client, who might
then complain about it, thereby uniquely identifying himself... ;-)

Good luck. This sort of thing can be fun if you like mysteries.

John

[Ed Sonneveld]

Hi John,

First, thanks for your very detailed reply.

1) Are the clients all running the same software and the same version of
the software?

Yes, it is the same software. It happens regardless of the version (the
software is updated regularly by me).

2) Are the clients all behind the same network infrastructure, or are some
at different sites or different companies?

Different sites, different companies.

3) Is there any correlation between any subset of clients and the
duplicate messages, or is duplication evenly distributed across all
clients? For instance, maybe it's only the clients at one site which are
having this problem.

It is not specific to certain clients; it happens to all. There are two
logging webmethods in the ws, and it happens to both.

4) Network-wise, on a given connection, TCP/IP is meant to prevent the
same bytes being delivered twice. You say you're seeing a web service
operation called twice (ever more than twice, BTW?) This implies that the
bytes making up the call are being delivered more than once, which, if
TCP/IP is working, should not happen _on the same connection_. So, maybe
something is duplicating the connection and the bytes sent on it.

More than twice even, in some cases even 3 and one case 4...
I also have the feeling something must be duplicating it.

5) Are you ever getting any errors which suggest that only _some_ of the
bytes are being duplicated? I don't know if there are any ASP.NET counters
for this, but it would be interesting if the duplication is of part of a
message as opposed to being of an entire message.

No, never had any errors like that.

Finally, if you can't solve this problem, or if it's not worth the time to
solve it, you could consider working around it. Have each client-side
request generate a GUID and a timestamp, and maybe some identifying
information about the client machine, and have them both sent with the
request. Record all in the database for debugging purposes, but use the
GUID to determine if the request is a duplicate. Unless the client-side is
issuing the request twice (fat fingers hitting a Submit button twice, for
instance), then you should be safe in ignoring (and flagging!) any request
with the same GUID as one already in the database. If your database code
is set up correctly, the absence of a given GUID in the database would be
proof that this is the original request; the presence would mean that it
is a duplicate and can be logged, and ignored.

I'd also throw an exception to get an error back to the client, who might
then complain about it, thereby uniquely identifying himself... ;-)

I was planning to do something like this, but was hoping that the cause
could be found somewhere.
BTW, when the request is proven a duplicate, I would prefer that the
original request is carried out and sends the result back to the client. If
I throw an exception I might give the user the idea that the request has
failed, while the first request is being carried out correctly. What would
be the best way of ignoring the duplicate request?

Good luck. This sort of thing can be fun if you like mysteries.

Thanks, I really hope this can be solved.

- Ed

[John Saunders]

"Ed Sonneveld" <esonneveld@sun_REMOVE_THIS_base.nlwrote in message
news:44**********************@news.xs4all.nl...

Hi John,

First, thanks for your very detailed reply.

You're welcome.

>I'd also throw an exception to get an error back to the client, who might
then complain about it, thereby uniquely identifying himself... ;-)

I was planning to do something like this, but was hoping that the cause
could be found somewhere.
BTW, when the request is proven a duplicate, I would prefer that the
original request is carried out and sends the result back to the client.
If I throw an exception I might give the user the idea that the request
has failed, while the first request is being carried out correctly. What
would be the best way of ignoring the duplicate request?

I'd consider throwing the exception, anyway, at least while trying to track
down the problem. If the client actually receives the corresponding SOAP
fault, then it indicates that the client was waiting for the duplicate
response, which would be interesting. If the clients never receive the SOAP
fault, then the question would be - who _does_ receive it?

I would not reply with the original reply, since that's actually lying, and
you don't want to lie to a computer. ;-)

You didn't, on the second attempt, take the first action. In fact, what you
did is ignore the request the second time.

If not a .NET-generated SOAP fault, or a custom-created one (by throwing
SoapException), I would add a "duplicate request" alternate success
response. That way, a client that cares can tell the difference between a
request that did something and one which was a duplicate. Even if you don't
care about the difference now, you may later.

John