This works perfectly about 99% of the time. What we are observing is that
there are certain situations where we encounter a deadlock scenario (and
that's what prompted my original question). Basically, req2a writes the
redirect back to the client, the client receives the redirect and actually
sends a request back to the server (verified this by using a proxy to
examine what is getting sent)... BUT - if req2a is already in the blocking
code, tomcat simply does not accept req3 until the blocking code times out!
Bad.
Are you absolutely sure of that?
Could you please triple-check it? A System.out.println("something") at the *very* beginning of the doGet/doPost method would be enough.
Without seeing the code, I'd say there is a missing notifyAll() or notify() somewhere, to wake up the thread that is wait()'ing.
Now what's interesting is that tomcat itself is not blocked at this point -
I can send requests from other browsers, and those get handled just fine. So
something seems to be happening where Tomcat cannot accept this particular
request (req3), perhaps because its still trying to keep the physical
connection associated with req2a open(?) (I'm thinking keep-alives here...in
other words, if the browser is using keep-alives, req3 will be coming across
the same physical connection as req2a, so its almost like tomcat thinks it
still can't receive a new request across this connection, although the
browser thinks its fine to go ahead and send it). But after req2a writes the
redirect response to the browser, I close the writer and flush the buffer -
there's nothing else I can do to say "hey, I really am done with that
response" (even though I'm going to continue running in the background on
the server and writing additional data - the real response, the report - to
a memory structure).
Strange... Unlikely... but possible...
One easy solution is just to modify our piped reader/writer so that when the
pipe size gets maxed it simply expands the size of the pipe. This would mean
that we'd never actually have to block, so we'd never hit our deadlock. The
downside is that it now means that in some cases we might be significantly
increasing the size of our memory footprint for the server. Another option,
I suppose, would be to simply pipe the document to disk, rather than storing
it to memory.
And you would not make your writer wait, so your process would be faster, wouldn't it?
HTH,
Antonio Fiol
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
