You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Carl Dreher <fo...@arn.net> on 2015/03/10 16:25:30 UTC
Re: threads vs. servlets
> If I write a servlet such as the above, is there ever only once instance of it running?
>> Don't confuse objects with threads. There is one instance of a particular servlet, but many threads may be executing in it concurrently, with each thread processing a separate request.
I understand that each request is handled by a separate thread. But does each thread have its own copy of the servlet code? Or does each thread request the use of the servlet, wait until it is available, use it, and then release it back to be used by the next thread, sort of like a database connection? I'm pretty sure it is the former, but just wanted to check.
> I'd like to offer a suggestion: In multiple places, the FAQs about using this list have comments such as "...be sure to check the archives before
> asking a question..." but don't have any links (or instructions) on HOW to do that!
>> There's no point in repeating something in a myriad of places that you must have already read in order to sign up for the mailing list. As clearly stated on the mailing lists page
>> (http://tomcat.apache.org/lists.html):
>> "Formatted archives are available in several places including the Apache Mail Archives, MARC, Nabble, and MarkMail. The raw mbox files are also available."
That presumes that someone searching for an answer is a member of this list. I suspect that there are many, many more people who have download and are trying Tomcat than are here. It is very likely someone finds a reference to a discussion through Google, and thus don't come through the Apache page "front door".
I actually did go to the Apache page you referenced when I started searching, and saw that line. The Apache Mail Archives link takes you to non-searchable records of every email. The MARC link returns a ridiculous list of hundreds of additional links, one of which is "tomcat users", which returns even more links, etc. I don't know WHAT Nabble is suppose to do...it seems to be about starting blogs. The MarkMail link is OK once you figure out what it does, but it is not as good as the simple link I provided. Oh, and none of the FAQ pages provide links or instructions on how to search the archive.
So, no, you don't have to repeat the instructions in myriad places. Just simply, cleanly explain it (with examples) in one place and then include links in myriad places. It is like putting a "contact us" link on every page of a website instead of just the home page: it simply makes it easier for the user. (Some people call it user-friendly. Personally, I just call it being helpful.)
- Carl Dreher
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: threads vs. servlets
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 3/10/15 8:15 PM, David Bullock wrote:
> On 11 March 2015 at 04:43, Christopher Schultz
> <chris@christopherschultz.net
>> wrote:
>
> Basically, making a
>> servlet threadsafe only requires you to avoid any non-threadsafe
>> class members in the servlet itself...
>
> Since we're tossing pennies, I've often wondered how the
> app-server achieves the effect that any instance-level fields set
> during an overridden setInitialContext(ServletContext) are
> guaranteed to 'happens-before' subsequent reads from overridden
> service(...) methods.
Do you mean init(ServletConfig) and other, similar things (like
ServletContextListeners, ServletContainerInitializers, Filters,
annotations, etc.)?
> I can only guess that the thread which invokes setInitialContext
> is the very same thread which *later *invokes aThread.start() on
> the worker threads
No, it's not necessarily that thread. Also, remember that the servlet
context (aka web app) can be un-deployed and re-deployed while the
server continues to run and serve requests.
So it's not that the threads aren't (yet) serving requests, it's that
the container knows that servlets must be initialized before they can
be used.
Conceptually, you can think of the container doing something like this:
1. Map the incoming request to a web application
2. If the web application is (re)loading, stall the request
Resume the request once the application is running again
3. Process the request by sending it through the filter chain
4. Process the request by sending it to the servlet
During (re)loading, the container marks the web application is
(re)loading, then initializes everything, then marks it as available.
These two processes (reloading and dispatching) can happen at any time
with respect to each other, so it's not a trick of nicely-timed threads.
Remember that threads just execute code; they won't have minds of
their own. The code they execute maintains coordination between the
different parts of the system. So, it's the request processing thread
itself that stalls while the web application is re-loading (in another
thread). The container is managing both of those processes because the
container's code is being executed by both threads, and can therefore
synchronize on appropriate objects, etc.
> ... there is a 'happens-before' relationship there, and since
> there is no volatile, final or synchronization involved, that's
> probably the one ... is it?
Remember that there is more code running than just what's in the
servlet. There is plenty of synchronization (though one technique or
another, not necessary using the "synchronized" keyword directly)
within the container itself within the container.
> That would kind of mean that when reloading a webapp, one would
> have to restart all the worker threads, right? Any comments?
No, they can keep going.
Tomcat actually does re-new request processing threads in the event
that a web application has left a ThreadLocal object whose Class was
loaded by the web applications' ClassLoader. If Tomcat didn't do that,
web applications could leave a huge footprint in the heap even after
they had been un-deployed.
> (I ask these only from curiosity).
>
> I stumbled across this in my IDE when I used an @ThreadSafe
> annotation on my servlet, but could put no @GuardedBy annotations
> on any of the instance fields, because I'm *not* actually using a
> lock or a synchronized block. (Thus my IDE whinged at me, and I
> retracted the @ThreadSafe from the Sevlet).
I can't comment on the use of annotations, since I am largely ignorant
of their use and implications (because I'm a hater), but that's the
IDE imposing that limit on you, not the compiler or the runtime.
I've found that it's rarely necessary to have instance fields in a
Servlet except for things that are really globally-accessible (to the
servlet, of course... anything truly global should be in a
ServletContext attribute). Anything that is an instance field must
either be threadsafe itself (e.g. java.util.Hashtable,
java.util.concurrent.ConcurrentHashMap, or a collection wrapped in
java.util.Collections.synchronized(Collection|List|Map)), or used in a
way that makes it thread-safe (e.g. wrap a synchronized{} block around
the usage, or restrict usage to a synchronized method -- which has the
same effect.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVAD44AAoJEBzwKT+lPKRYfTIQAI+SmQ0RApZwrFRp9rnx786J
mjLnckm33vhUf+btgT5733OUQF2a+Jmj76SuESuyI7JA3ozPlj5UX0Mr+1TJPrK8
NYzBTSDeFJoM1pojR73PMWUaurEzFG6c517VYKrNEhrKNBdwYB3Tha3mW6uobn/R
v/0HBhC/hROjFtAdD6kymtBCO6ToH+3F5NuaizzF44cMy1IrxcYWhe5a4Xf69mVR
4P4rfXtztGULG+BUK2aTdwMYU0QLqae8MGDwYIhuJ2H1ExuF6mhWtH20+U8ZbTSI
NckLWsMTyNOcVS86W++Ceoq2/qmP79thqN8tPy5Z7vL/+qZ8JeKlKPKPaUPpFHY6
lsKMZ0SFCefHPKbVVD/5sH77G7YptZn92asgpZMVh4dGIBsSTangveSnjMqSO4G5
F9U07oU2QemGQ4dK15KpNqis4aFQKCX9EiKwRSFlBe/bVFc64YfSCUlitiuU1wiR
w29L+Rc04cZ0ImbLTsTunFK0SSKlUGxI5UwZ3dPadrl/TyV6oKTqjFCVYc1a0ZtV
WR3PJTFsfWs0zXtTFDZqtWVSNatjDXnRsGIxksPFTceZ0oU8r94PQux13yNAz56N
nr4iSEnrBg7IOPBFt2UZvPwWDGohTYwncLJF7fsOnjr4NWrBRIts3eZCnw9hPVcC
0CtHKu08oCm7ra92H//D
=CicN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: threads vs. servlets
Posted by David Bullock <da...@machaira.com.au>.
On 11 March 2015 at 04:43, Christopher Schultz <chris@christopherschultz.net
> wrote:
Basically, making a
> servlet threadsafe only requires you to avoid any non-threadsafe class
> members in the servlet itself...
>
Since we're tossing pennies, I've often wondered how the app-server
achieves the effect that any instance-level fields set during an overridden
setInitialContext(ServletContext) are guaranteed to 'happens-before'
subsequent reads from overridden service(...) methods. I can only guess
that the thread which invokes setInitialContext is the very same thread
which *later *invokes aThread.start() on the worker threads ... there is a
'happens-before' relationship there, and since there is no volatile, final
or synchronization involved, that's probably the one ... is it? That would
kind of mean that when reloading a webapp, one would have to restart all
the worker threads, right? Any comments?
(I ask these only from curiosity).
I stumbled across this in my IDE when I used an @ThreadSafe annotation on
my servlet, but could put no @GuardedBy annotations on any of the instance
fields, because I'm *not* actually using a lock or a synchronized block.
(Thus my IDE whinged at me, and I retracted the @ThreadSafe from the
Sevlet).
cheers,
David.
Re: threads vs. servlets
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Carl,
Others have already responded, but I figured I'd add my two cents, too.
On 3/10/15 11:25 AM, Carl Dreher wrote:
>> If I write a servlet such as the above, is there ever only once
>> instance of it running?
>
>>> Don't confuse objects with threads. There is one instance of
>>> a particular servlet, but many threads may be executing in it
>>> concurrently, with each thread processing a separate request.
>
> I understand that each request is handled by a separate thread.
> But does each thread have its own copy of the servlet code?
No. The code itself is ... just code. Do you mean "does each thread
have a separate instance of the [whatever]Servlet class to use"?
That's usually not the case, either.
> Or does each thread request the use of the servlet, wait until it
> is available, use it, and then release it back to be used by the
> next thread, sort of like a database connection?
There is a marker interface called SingleThreadModel that can be used
to indicate that a servlet is NOT threadsafe and therefore must only
be accessed by a single thread at a time. Most containers will
automatically create a handful of instances so that multiple threads
can use that servlet at once -- though they will be working with
different instances of the servlet.
That interface was deprecated in Servlet 2.4 with no replacement, but
since the API is supposed to be backward-compatible, the damage has
been done and therefore SingleThreadModel must be supported ... pretty
much forever.
Anyhow, if your servlet is not threadsafe, you're doing it wrong and
should fix your servlet.
Note that any local references and objects that are used /inside/ of
the service(...) method are usually thread safe. Basically, making a
servlet threadsafe only requires you to avoid any non-threadsafe class
members in the servlet itself... and to make sure any other objects
you access are thread-safe or you are sure aren't visible to other
threads (a good bet if your thread creates those objects and doesn't
leak references anywhere that is visible to other threads).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU/y1OAAoJEBzwKT+lPKRYQH0P/08BynLMXtljQ7EFdJ7SVKvS
cUPIYGE31Nzk4f7GlV4lpWiS5U32dimMsa9IAZIbvaxz+dPTubaIgbN4QbFmwEbU
SlQ9wYjZPxM5CBRSI1x5o0wjlWoeo8Qq7WKl8JvqIMjpqaaHKFivt9SlwupuC0za
UR6h1y0xhNizwWBQaN5NfSsXy/12TUlwivSfD9jDrokKsnGpncN3v+0sZ7u2e5vF
pUKZ1Ad0OuLFC4Yjt4YI8cMjAkapqJOUIZ5UWiFiVJ1tC6YUk4H403ydgQW6pMWV
AaX+q5XicrbjeSfzYk45YZZi1DM0fItQdICv5+WBJgphr3dtu5cW9BBP/CXZWWfs
Y90JoTBNXQRLBUvXkf59nmjMcIUYrCj6fxyyGz3NmuGDzdDyGh4Ep9dQQACWsCez
8fSi9Zlxmau9KZSh51Fm/pKpiar3WxcNWIupiOYfG1rNAktbHW0RDmneJWmrx07Q
ShaSbDKrZ2VxFE0p4O97RwivgTfYYt+iEQYenqKB4wiiQ87xcKM5Z1kk/2MFqRQU
TyVa2h3laLLGdBY5Hwejb5blDHK99dfk40ZECUj4PIMJSYdcqxkAvoUBiAhVG6eD
ArRVSah4+0p9b7eAk5a12OhzQcf99GEusHcAy1AYKncJeVCpbqY131jQBG90LX3c
JyxPYKSX1o6jqe+9eYh2
=WEpx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: threads vs. servlets
Posted by Kaydell Leavitt <ka...@yahoo.com.INVALID>.
Unsubscribe.
Please?!
-- Kaydell
kaydell@yahoo.com
On Mar 10, 2015, at 9:25 AM, Carl Dreher <fo...@arn.net> wrote:
>> If I write a servlet such as the above, is there ever only once instance of it running?
>
>>> Don't confuse objects with threads. There is one instance of a particular servlet, but many threads may be executing in it concurrently, with each thread processing a separate request.
>
> I understand that each request is handled by a separate thread. But does each thread have its own copy of the servlet code? Or does each thread request the use of the servlet, wait until it is available, use it, and then release it back to be used by the next thread, sort of like a database connection? I'm pretty sure it is the former, but just wanted to check.
>
>> I'd like to offer a suggestion: In multiple places, the FAQs about using this list have comments such as "...be sure to check the archives before
>> asking a question..." but don't have any links (or instructions) on HOW to do that!
>
>>> There's no point in repeating something in a myriad of places that you must have already read in order to sign up for the mailing list. As clearly stated on the mailing lists page
>>> (http://tomcat.apache.org/lists.html):
>>> "Formatted archives are available in several places including the Apache Mail Archives, MARC, Nabble, and MarkMail. The raw mbox files are also available."
>
> That presumes that someone searching for an answer is a member of this list. I suspect that there are many, many more people who have download and are trying Tomcat than are here. It is very likely someone finds a reference to a discussion through Google, and thus don't come through the Apache page "front door".
>
> I actually did go to the Apache page you referenced when I started searching, and saw that line. The Apache Mail Archives link takes you to non-searchable records of every email. The MARC link returns a ridiculous list of hundreds of additional links, one of which is "tomcat users", which returns even more links, etc. I don't know WHAT Nabble is suppose to do...it seems to be about starting blogs. The MarkMail link is OK once you figure out what it does, but it is not as good as the simple link I provided. Oh, and none of the FAQ pages provide links or instructions on how to search the archive.
>
> So, no, you don't have to repeat the instructions in myriad places. Just simply, cleanly explain it (with examples) in one place and then include links in myriad places. It is like putting a "contact us" link on every page of a website instead of just the home page: it simply makes it easier for the user. (Some people call it user-friendly. Personally, I just call it being helpful.)
>
> - Carl Dreher
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: threads vs. servlets
Posted by Neven Cvetkovic <ne...@gmail.com>.
Hey Carl,
On Tue, Mar 10, 2015 at 11:25 AM, Carl Dreher <fo...@arn.net> wrote:
> If I write a servlet such as the above, is there ever only once instance
>> of it running?
>>
>
> Don't confuse objects with threads. There is one instance of a
>>> particular servlet, but many threads may be executing in it concurrently,
>>> with each thread processing a separate request.
>>>
>>
> I understand that each request is handled by a separate thread. But does
> each thread have its own copy of the servlet code? Or does each thread
> request the use of the servlet, wait until it is available, use it, and
> then release it back to be used by the next thread, sort of like a database
> connection? I'm pretty sure it is the former, but just wanted to check.
Chuck pointed you to the Servlet API specification. Read upon how Servlets
work, e.g.
https://jcp.org/aboutJava/communityprocess/final/jsr340/index.html
Your servlet will likely extend from HttpServlet (see JavaDocs here -
https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/http/HttpServlet.html
)
There is exactly one (object) instance of your servlet in your application
context. Tomcat is a multi-threaded server (out-of-box), so you need to be
careful with writing your servlet code, make sure it is thread-safe (e.g.
synchronize access to shared resources, use local variables, etc). Your
servlet constructor and servlet init method are going to be called only
once when the servlet is initialized. Subsequently, service methods are
going to be called and executed concurrently by multiple threads, e.g.
doGet(), doPost(), etc...
So, to answer your question - the threads are not waiting for other threads
to finish, unless you introduced synchronization somewhere in your servlet
code. Synchronization will slow things down, but it might be necessary to
make things thread-safe. Avoid synchronization if you can :)))
Hope that helps!
Cheers!
Neven
RE: threads vs. servlets
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Carl Dreher [mailto:focusrsh@arn.net]
> Subject: Re: threads vs. servlets
> > > If I write a servlet such as the above, is there ever only once instance of it running?
> > Don't confuse objects with threads. There is one instance of a particular servlet, but
> > many threads may be executing in it concurrently, with each thread processing a separate
> > request.
> But does each thread have its own copy of the servlet code?
Why would anyone ever duplicate _code_? Perhaps you mean the instance fields of the servlet object?
> Or does each thread request the use of the servlet, wait until it is available, use it, and
> then release it back to be used by the next thread, sort of like a database connection?
Note the use of the word "concurrently" above; is that not clear? Since the threads are executing at the same time within the servlet, one should be very, very careful about using instance or static fields during request processing. Such mistakes are a common cause of garbled responses.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org