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
[quoted text clipped - 11 lines]
> 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 - 01 Sep 2006 01:05 GMT
> 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... ;-)
[quoted text clipped - 6 lines]
> 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