Hi Antonio,
> 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.
Yeah. I'm basing it on the timestamps in the log4j log messages (which I've
never yet seen to be wrong). And I've verified it numerous times.
> Strange... Unlikely... but possible...
Yeah, that's what I thought too.
> And you would not make your writer wait, so your process would be
> faster, wouldn't it?
Yes, it would be faster (at least theoretically, although in practice
blocking doesn't occur unless the pipe fills up...so by tuning the size of
your pipe you should be able to come up with something that is just as fast,
in XX% of the cases). The downside of writing the whole thing to memory is
that in this small percentage of scenarios, the entire document gets written
to memory first, and if its a report that is hundreds of pages long, its
possible to run your server out of memory under load.
So the piped approach (if I could get it to work), would be preferable, even
if there's a slight hit on throughput. But if I can't, I can live with the
in-memory version.
Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"
> -----Original Message-----
> From: Antonio Fiol Bonnin [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 21, 2004 3:42 AM
> To: Tomcat Users List
> Subject: Re: thread deadlock problem
>
>
> Christian Cryder wrote:
>
> >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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
