On 08/07/2011 11:07, peterjca wrote: > > Yes, I do mean duplicate requests. I know they are duplicates because the > header contains the unique (thread-safe) counter that my test harness > increments. Each request should contain its unique "request count", but some > requests contain counts already seen before -- hence they are being > duplicated/resent for some reason by something which is not my web app nor > my test harness. > > I maintain a unique thread-safe count in the test harness. That shows the > test is sending the correct number of requests.
I'm not sure that's a safe assumption. It most likely only shows that the test is sending the right number of requests, rather than that the IO component it relies on is performing correctly. If you're saying that Tomcat is seeing the same headers in multiple requests it points to the client resending the request. Tomcat doesn't arbitrarily resend a request to itself if a timeout occurs. Can you use a network sniffer to inspect the network traffic to Tomcat? p > On the server-side in the Jersey resource end-point, purely for debug > purposes, I am using a bitset to maintain the counts already seen from the > headers of the incoming requests. That demonstrates that I am receiving > duplicate requests on the server. > > Everything is standalone on my machine. Nothing else is using the web app as > it's a greenfield project under my sole development. > > It's the standard standalone Tomcat configuration. > > My web app uses 2-legged OAuth for authentication using a Jersey > ResourceFilter. That has always worked and is not the cause of any failures. > > In fact, all of my Jersey client requests from the test harness return 200 > response codes. > > I'll run Tomcat 7 and check the access logs. >
signature.asc
Description: OpenPGP digital signature
