Hi, Yes, you will definitely get those types of answers on the user list. Yoav Shapira Millennium Research Informatics
>-----Original Message----- >From: Christian Cryder [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 18, 2004 4:14 PM >To: Tomcat Developers List >Subject: RE: thread deadlock problem > >Hi Yoav, > >The reason I asked on this list is because 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 > >Now if this IS a case of bad design, then I'd like an explanation of _why_. > >If I can get that kind of answer on the users list, then I'd be happy to >move the conversation there (just let me know) > >thanks, >Christian >---------------------------------------------- >Christian Cryder >Internet Architect, ATMReports.com >Project Chair, BarracudaMVC - http://barracudamvc.org >---------------------------------------------- >"Coffee? I could quit anytime, just not today" > > >> -----Original Message----- >> From: Shapira, Yoav [mailto:[EMAIL PROTECTED] >> Sent: Thursday, March 18, 2004 3:57 PM >> To: Tomcat Developers List >> Subject: RE: thread deadlock problem >> >> >> >> Hi, >> Stop processing after you redirect: anything else is bad design with >> unpredictable results. Also, this is not a tomcat-dev question but a >> tomcat-user issue, so please continue this discussion there (if you want >> to continue it at all). >> >> Yoav Shapira >> Millennium Research Informatics >> >> >> >-----Original Message----- >> >From: Christian Cryder [mailto:[EMAIL PROTECTED] >> >Sent: Thursday, March 18, 2004 3:53 PM >> >To: Tomcat-Dev >> >Subject: thread deadlock problem >> > >> >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? >> > >> >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] >> >> >> >> >> This e-mail, including any attachments, is a confidential >> business communication, and may contain information that is >> confidential, proprietary and/or privileged. This e-mail is >> intended only for the individual(s) to whom it is addressed, and >> may not be saved, copied, printed, disclosed or used by anyone >> else. If you are not the(an) intended recipient, please >> immediately delete this e-mail from your computer system and >> notify the sender. Thank you. >> >> >> --------------------------------------------------------------------- >> 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
