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]
RE: thread deadlock problem
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]
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?
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]
RE: thread deadlock problem
Why are you trying to do this kind of control?
--
De: Christian Cryder[SMTP:[EMAIL PROTECTED]
Responder:Tomcat Users List
Enviada: sexta-feira, 19 de março de 2004 9:55
Para: Tomcat-User
Assunto: 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?
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]
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]
RE: thread deadlock problem
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.
I can (and will) look at both of these if need be, but first I'd prefer to
hear if there is something obvious that exlains the behavior of tomcat - I'd
really like to understand why what we're doing only deadlocks in a very
small percentage of our cases. I'd like to understand why our blocking code
does not allow tomcat to continue (as I'd expect), and why tomcat can't turn
around and accept req3 from the browser in this situation.
Long answer to a short question, but hopefully that helps flesh things out.
THanks much,
CHristian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
Coffee? I could quit anytime, just not today
-Original Message-
From: Edson Alves Pereira [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 8:00 AM
To: 'Tomcat Users List'
Subject: RE: thread deadlock problem
Why are you trying to do this kind of control?
--
De: Christian Cryder[SMTP:[EMAIL PROTECTED]
Responder: Tomcat Users List
Enviada:sexta-feira, 19 de março de 2004 9:55
Para: Tomcat-User
Assunto: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?
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]
RE: thread deadlock problem
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]
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]
RE: thread deadlock problem
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
RE: thread deadlock problem
, 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]
