the attachments didn't make it, but here are some thoughts (maybe I am telling you stuff you knew all along, then I'm sorry I didn't know).
That the whole thing craps out when using sleep is probably logical, because an important difference is that wait releases the monitor held by a thread, while sleep does not. In other words when executing:
sleep (10000)
the thread blocks for 10 seconds, but since it's holding a monitor (because you are in a synchronized block), no other threads can call any other synchronized methods/enter any synchronized blocks during that time.
When executing:
wait (10000)
the thread blocks for 10 second but releases the monitor it is holding, so even though it might currently be executing some code in a synchronized block, it releases its monitor and blocks so other threads can enter the synchronized parts.
Have you tried to reproduce the problem without any synchronized statements in there?
When 2 different threads execute 2 different methods on the same object, while both methods are synchronized they can still prevent each other execution. I had a deadlock situation a few days ago, because in one method I executed a join statement on a thread, which caused the method to block, which in turn prevented all other threads to create a condition in which the thread that the joining thread was waiting could complete (uh... are you still with me on that ;-)?).
Anywayz, as far as I can help you (so hopefully anybody else has a clear solution for you):
1. play around with the synchronize statements
2. print thread id's to the log so you have some more info about which thread is doing what
3. don't do it all in the same thread! If you compare this with the swing classes (as far as that is appropriate), it will never work performing some task and updating a gui in one and the same thread. Create something like a threadpool as a static field in the main servlet, that maps sessionids to a workerthread or something like that.
4. or try to send the files again ;-) so I can see the source
can't promise i can help, can't promise i have the time, can only give it a try ;-)
oh yeah one other thing that might help (it caused another deadlock situation in a program i was working on ;-)): a thread can hold more than one monitor. Imagine you have object anA of class A & object aB of class B. Method a() in anA calls b() in aB. Imagine a() & b() are both synchronized. Method b() does some stuff and calls wait(). Thread one calls a(), a() delegates to b(), b() calls wait() so thread one releases the monitor on object aB. Now thread two calls a(). Thread one is no longer holding the monitor for aB, so you'd suspect thread two can easily execute b(). However since the call has to be passed through a() which is synchronized and anA's monitor is still being held by thread one, thread two blocks, whereas if a() hadn't been synchronized, it wouldn't have. (if there is any way I could explain this even worse I'd like to know ;-)).
uhmm... well... the attachments please ;-) ?
Grtz Hans
At 12:51 19/03/2004 -0500, you wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
