Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: 
 <B2A93657A837D5118A2F009027E868EC603C31@ussfhqmbx01.etranslate.com>
From: "Schreibman, David" <DSchreibman@eTranslate.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: RE: DO NOT REPLY [Bug 3851]  -     SingleThreadModel ignored
Date: Mon, 1 Oct 2001 09:53:03 -0700 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

FYI: I'm taking a look at implementing a pool for this since it seems like a
fun task.  If nobody beats me to it, I'll post my attempt when it's ready.

-David

> -----Original Message-----
> From: Bill Barker [mailto:wbarker@wilshire.com]
> Sent: Sunday, September 30, 2001 9:22 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: DO NOT REPLY [Bug 3851] - SingleThreadModel ignored
> 
> 
> While pooling was a very nice feature of JServe (which I have 
> personally
> taken advantage of in the past), the operative word in the 
> spec is "may".
> The 3.x and 4.0 implementations are entirely within their 
> rights within the
> spec to simply synchronize.
> 
> In other words, this comes under the "if it itches, scratch 
> it yourself"
> clause of OS development. (personally, I can still tolerate 
> the itching, but
> would +1 someone else taking this on).
> ----- Original Message -----
> From: <bugzilla@apache.org>
> To: <tomcat-dev@jakarta.apache.org>
> Sent: Sunday, September 30, 2001 5:37 PM
> Subject: DO NOT REPLY [Bug 3851] - SingleThreadModel ignored
> 
> 
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3851>.
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3851
> >
> > SingleThreadModel ignored
> >
> >
> >
> >
> >
> > ------- Additional Comments From bojan@binarix.com  2001-09-30
> 17:37 -------
> > After reading the source for TC 3.3, I can now see I was 
> totally wrong
> about the
> > pool approach. There are comments about it in the code, but 
> it doesn't
> seem to
> > be implemented. JServ used to use the pool approach (as in: good old
> JServ!), so
> > I thought this must be the case in TC as well. I missed one 
> minor detail
> here:
> > JServ and Tomcat have nothing to do with one another...
> >
> > I have found this code snippet in ServletHandler.java of TC 3.3:
> >
> > --------------------------------------------------------
> >  if (servlet instanceof SingleThreadModel) {
> >    synchronized(servlet) {
> >      servlet.service(reqF, resF);
> >    }
> >  } else {
> >    servlet.service(reqF, resF);
> >  }
> > --------------------------------------------------------
> >
> > which suggest that during the execution of service(), servlet is
> synchronised
> > for SingleThreadModel. This is a piece of code from JspServlet.java:
> >
> > --------------------------------------------------------
> >  if (servlet instanceof SingleThreadModel) {
> >    // sync on the wrapper so that the freshness
> >    // of the page is determined right before servicing
> >    synchronized (this) {
> >      servlet.service(request, response);
> >    }
> >  } else {
> >    servlet.service(request, response);
> >  }
> > -------------------------------------------------------
> >
> > which also suggests syncronisation for SingleThreadModel.
> >
> > Can someone that understands this whole thing a bit better 
> comment. I
> think we
> > should be very clear in release notes of TC 3.3 if it 
> doesn't comply with
> parts
> > of the spec.
> >
> > From the code, it seems to be compliant...
> >
> >
> 
> 
> *----*
> 
> This message is intended only for the use of the person(s) 
> listed above 
> as the intended recipient(s), and may contain information that is 
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
> you may not read, copy, or distribute this message or any 
> attachment.  
> If you received this communication in error, please notify us 
> immediately 
> by e-mail and then delete all copies of this message and any 
> attachments.
> 
> 
> In addition you should be aware that ordinary (unencrypted) 
> e-mail sent 
> through the Internet is not secure. Do not send confidential 
> or sensitive 
> information, such as social security numbers, account 
> numbers, personal 
> identification numbers and passwords, to us via ordinary 
> (unencrypted) 
> e-mail. 
>