If the POST request is simply a signal for the server to perform some task
without sending any pending output to the client, he could make an object that
contains all of the important information from the request object, and put this
"logical clone" into the queue.
jim
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 06, 2000 3:12 PM
Subject: Re: doPost() and concurreny issue/question
> "Heinemann, Andreas" wrote:
>
> > Hi,
> >
> > i've got a question/problem concerning the doPost() method.
> >
> > As far as I know, whenever there is a new request, tomcat creates
> > a new thread running through the doPost() method.
>
> This is not precisely correct in all circumstances. In both Tomcat 3.2 and
4.0,
> threads are pooled and re-used, rather than being created every time, for
> performance reasons.
>
> > Inside this
> > method, my code does nothing special. But is passes the request and
> > response objects to a queue. this queue is managed by other threads.
> > then doPost() finishes.
> >
> > My question is: What happens to the request response objects when
> > doPost() ends?
> >
> > It looks to me, that tomcat does some kind of cleanup, especially
> > doing something with the stream objects attached to the
> > request/response objects.
> >
>
> All versions of Tomcat recycle the request and response objects that were used
> by a previous doPost() or doGet(). When these objects are re-used, the input
> and output streams get attached to the new request's TCP/IP socket. Note that
> this re-use might be on the same thread, or might be on some other thread.
>
> As a consequence of this, you are not allowed to maintain a reference to the
> request or response objects outside the scope of the current request
processing
> (i.e. the call to your doGet() or doPost() method).
>
> >
> > I've outlined some code in the 'first scenario' and got unexpected
> > behavior. Seldom there occurs no error. Most of the time a client, who
> > is reading the response, gets an java.io.StreamCorruptedError.
> > Sometimes it is an java.io.EOFException.
> >
> > In the 'second scenario', I block the doPost()-thread, therefore making
> > sure,
> > that the request and response objects are still there and valid.
> > Now there is no such problem.
> >
> > Any ideas?
> >
>
> Yep. Scenario 1 is illegal and will generate undefined results that differ
> depending on which servlet container you run them in.
>
> Scenario 2 illustrates why your approach is redundant anyway -- all you are
> doing is adding extra overhead. Let the servlet container worry about
threads,
> and have your servlets concentrate on creating the responses.
>
> >
> > thanks, andreas
> >
> > ps: i'm using tomcat 3.1 and java 1.3 under winNT
> >
>
> You should really really really upgrade to 3.2. There are lots of bugs that
> have been fixed, and performance is improved as well.
>
> Craig McClanahan
>
>
>
