ok,
and can you give some more details on the blocking code.
I assume :
...check to see if data pipe still full
> > ...timeout if we've waited too long
> >
> > notifyAll();
> > try {
> > wait(1000);
> > Thread.yield();
> > } catch (InterruptedException ex) {
> > throw new java.io.InterruptedIOException();
> > }is performed repeatedly in a while lus? What's the notifyAll doing there by the way? And is this code being executed in a synchronized block?
grtz Hans
At 09:01 19/03/2004 -0500, you wrote:
> is the thread mentioned in 2b the same as the one that handled 2a ?
Yep, same thread.
---------------------------------------------- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org ---------------------------------------------- "Coffee? I could quit anytime, just not today"
> -----Original Message----- > From: Hans [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 8:21 AM > To: Tomcat Users List > Subject: Re: thread deadlock problem > > > hi, > is the thread mentioned in 2b the same as the one that handled 2a ? > > grtz > Hans > > At 07:55 19/03/2004 -0500, you wrote: > >Hi folks, > > > >I need to know if someone can explain the following behavior: > > > >1. client browser issues a request > >2. tomcat servlet code starts handling the request... > > a. writes an html redirect to the resp, flushes the buffer, etc > > b. thread continues processing (writing to a data structure) > >3. client browser receives 2a response and generates another request... > > a. reads data out of the data structure populated by 2b > > > >What's happening is that 2b fills up the structure and then > blocks, waiting > >until 3a reads some of the data out, so that it can continue. > The blocking > >code looks like this: > > > > ...check to see if data pipe still full > > ...timeout if we've waited too long > > > > notifyAll(); > > try { > > wait(1000); > > Thread.yield(); > > } catch (InterruptedException ex) { > > throw new java.io.InterruptedIOException(); > > } > > > >Now what is happening is that in certain situations, the request for 3a > >never gets accepted by the server until 2b times out. I'm trying to > >understand why (and what to do about it). I have verified that the client > >not only receives the response from 2a, but it actually issues > the request > >for 3a. Nevertheless, once Tomcat is in this blocking code > (above) it does > >not seem to accept requests from this particular browser window, > -UNTIL- 2b > >times out. > > > >Can anyone explain this to me? Should I be blocking/yielding in > some other > >fashion? Why won't Tomcat accept my subsequent requests when I'm in this > >blocking code? > > > >What I'm looking for more than just "that's a stupid thing to do" - I'm > >hoping someone can either > > > >a) explain the nitty-gritty of how tomcat handles writing the > code back to > >the browser (and telling the browser that everything is complete) in the > >case where the thread may actually need to continue running for a longer > >period of time -or- > > > >b) offer some constructive suggestions as to where I should > start looking in > >the tomcat code to answer those questions myself > > > >Any suggestions would be greatly appreciated... > > > >tia, > >Christian > >---------------------------------------------- > >Christian Cryder > >Internet Architect, ATMReports.com > >Project Chair, BarracudaMVC - http://barracudamvc.org > >---------------------------------------------- > >"Coffee? I could quit anytime, just not today" > > > > > >--------------------------------------------------------------------- > >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] > > > --------------------------------------------------------------------- > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
