Hi Hans,
> is performed repeatedly in a while lus?
Yep. It's basically the same as Sun's PipedReader/PipedWriter, but modified
to support the notion of a configurable pipe size and a timeout. I am
attaching the actual classes so you can see them (cf. line 218 in
BetterPipedReader)
> What's the notifyAll doing there by the way?
Well, its in there because the Sun code had it in there. My understanding of
what's going on is that if the writer blocks it does a notifyAll to wake up
any pending readers, and the readers do something similar when they read (to
wake up any pending writers that may be blocked because the pipe was full).
My understanding of their use of wait is a little shakier - I thought that
substituting sleep(xxx) instead would basically do the same thing, but it
doesn't - the whole thing craps out then. So I left it as wait()
> And is this code being executed in a synchronized block?
Yep. Its happening in
protected synchronized void receive(int c)
But the writer thread (req2a) is the only thread calling this method. The
reader thread (req3 - when it gets there) will be calling
public synchronized int read()
Its interesting to me that the way Sun has implemented this, they don't
actually have to synchronize access to the underlying data structure (a
char[]) - they just have 2 indexes: one for read position and one for write
position. I thought was kind of clever. But they are still synching on the
methods, so I'm not sure whether they're actually gaining much in
performance or not.
Christian
----------------------------------------------
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 9:33 AM
> To: Tomcat Users List
> Subject: RE: thread deadlock problem
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
