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]

Reply via email to