On 12/29/2014 6:52 PM, Tony Garnock-Jones wrote:
On 12/29/2014 06:30 PM, Neil Van Dyke wrote: > Maybe someone who has the problem could use JMeter (or "ab", or similar) > to pound the server and reproduce the failure quickly, under debugging > conditions?I've tried ab on it: - many-requests doesn't seem to provoke the fault; - rapid-requests doesn't seem to provoke the fault; - I don't believe I've tried high-concurrency requests though. (Only moderate-concurrency, so far.) I also haven't yet run any HTTP fuzz tester against the server. I think doing so would be a very, very good idea. Does anyone have suggestions for a good HTTP fuzzer?
Mine was a low concurrency situation - I was debugging a web page that uses XHR quite heavily. Each time I stopped the browser, there could have been as many as 5 outstanding requests targeting 3 different servlets. I was working for about an hour - the server application survived a good many iterations before it stopped responding.
I think it's important to note that the connections were being broken - timing out or aborted - by my actions debugging in the browser. It was not a situation where concurrency or request volume clearly was the culprit.
I don't see this particular scenario occurring very often (or even ever) in deployment. My fear is that there might be some kind of creeping crud problem involving broken connections that eventually will cause the server to stop even if connections are broken only sporadically (as might be expected in real world usage).
George ____________________ Racket Users list: http://lists.racket-lang.org/users
