Here's something else that's intresting:

If you run the code that puts your servlet in a loop it will "kill" your
JVM and other servlets in a different context will not be able to
respond either. This seams like an issue with the JVM rather than the
servlet implementation. I tested this with JDK 1.3.1, Tomcat 4.1 under
FreeBSD. I'd be curious to know if implementations that use native
threads (Windows, Solaris) handle this more gracefully.

> > >>>if (sOpcion.equals("SS")) {
        > > >>>
        > > >>>>>     while ( true )
        > > >>>>>      ;
        > > >>>>>    }
        >


On Fri, Dec 13, 2002 at 01:23:39PM -0600, Milt Epstein wrote:
> On Fri, 13 Dec 2002, Eric Noriega wrote:
>
> >     I'm not sure if there has been a change in the spec., but my
> > understanding was that multiple instance of the servlet would be
> > created.  Each one is a single thread class, but there can be
> > multiple of them.  The cost is in the class turnover, not in the
> > fact that each request is blocked.
>
> It's not so much a change in the spec, but rather a detail that isn't
> covered in the spec.  That is, SingleThreadModel is discussed in the
> spec, as to how it is to behave, but not how it is to be implemented.
> A particular implementation could create a single instance that blocks
> when another request/thread comes through, or they could create a pool
> of instances to handle (some number of) multiple simultaneous
> requests/threads.
>
> So servlet containers have a choice how to implement it.  And that
> includes a particular servlet container changing how it implements it
> between versions.  And, in fact, I think this is what happened, I just
> saw a post about it on the tomcat-user list, Tomcat 3.x did it one way
> (no pool of instances), Tomcat 4.x did it another (a pool of
> instances) -- or something like that.  That could explain the behavior
> being seen here.
>
> BTW, have I included in this thread yet my comment about how
> SingleThreadModel is a bad solution and should be avoided? :-).  Check
> the list archives for more info on this.
>
>
> > Adrian Janssen wrote:
> >
> > >The servlet is blocked with one thread inside it. When you make the
> > >call with another browser window it starts NEW SECOND thread. This
> > >thread is NOT LET INTO the servlet because it implements the
> > >SingleThreadModel and there is ALREADY ONE THREAD INSIDE IT.
> > >
> > >The 4.1 on W2K seems to be incorrect - it should behave like 3.2.1
> > >on linux!!!!
> > >
> > >>-----Original Message-----
> > >>From: Patricio Vera S. [SMTP:[EMAIL PROTECTED]]
> > >>Sent: 10 December 2002 03:22
> > >>To:   [EMAIL PROTECTED]
> > >>Subject:      Re: servlet implementing SingleThreadModel
> > >>
> > >>    That's is the idea, block the servlet so when call with another
> > >>browser instance force to execute a new thread....
> > >>
> > >>    It's semms ok in tomcat 4.1 on W2K but not in tomcat 3.2.1 on linux.
> > >>
> > >>Saludos,
> > >>Patricio Vera S.
> > >>
> > >>
> > >>----- Original Message -----
> > >>From: "Partha Ranjan Das" <[EMAIL PROTECTED]>
> > >>To: <[EMAIL PROTECTED]>
> > >>Sent: Tuesday, December 10, 2002 3:10 AM
> > >>Subject: Re: servlet implementing SingleThreadModel
> > >>
> > >>
> > >>>if (sOpcion.equals("SS")) {
> > >>>
> > >>>>>     while ( true )
> > >>>>>      ;
> > >>>>>    }
> > >>>>>
> > >>>What does this code do? it will loop eternally.
> > >>>
> > >>>-----Original Message-----
> > >>>From: Adrian Janssen [mailto:[EMAIL PROTECTED]]
> > >>>Sent: Tuesday, December 10, 2002 12:27 PM
> > >>>To: [EMAIL PROTECTED]
> > >>>Subject: Re: servlet implementing SingleThreadModel
> > >>>
> > >>>
> > >>>SingleThreadModel means that only one thread is allowed to run in your
> > >>>servlet at a time. So what is happening is with your first call to the
> > >>>servlet a thread starts to execute in the servlet - but it never leaves
> > >>>
> > >>the
> > >>
> > >>>servlet, as per yopur code. It thereby blocks the second call which will
> > >>>start a new thread that will try to run through the servlet but due to
> > >>>
> > >>the
> > >>
> > >>>fact the thread from the first call is still running in the servlet the
> > >>>second call's thread is blocked due to the restrictions of the
> > >>>SingleThreadModel.
> > >>>
> > >>>So if anything the W2K implementation seems like it might be incorrect,
> > >>>
> > >>but
> > >>
> > >>>I suspect that it is setup differently, perhaps with a very short
> > >>>
> > >>timeout.
> > >>
> > >>>Cheers
> > >>>Adrian
>
> Milt Epstein
> Research Programmer
> Integration and Software Engineering (ISE)
> Campus Information Technologies and Educational Services (CITES)
> University of Illinois at Urbana-Champaign (UIUC)
> [EMAIL PROTECTED]
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>

--
Dror Matalon
Zapatec Inc
1700 MLK Way
Berkeley, CA 94709
http://www.zapatec.com

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to