DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884.
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=3884
SingleThreadModel servlets not pooled results in low performance
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2003-07-18 22:12 ---
With 4.1.24, I make a simple isThreadSafe=false jsp with only:
try {
System.out.println(Before sleep, instance is +this+ time
is +System.currentTimeMillis());
Thread.sleep(60*1000);
System.out.println(After sleep, instance is +this+ time
is +System.currentTimeMillis());
} catch(InterruptedException ex) {}
and at the moment, it serializes, as hitting it w/ 2 browsers leads to:
Before sleep, instance is [EMAIL PROTECTED] time is 1058566078026
After sleep, instance is [EMAIL PROTECTED] time is 1058566138034
Before sleep, instance is [EMAIL PROTECTED] time is 1058566138034
After sleep, instance is [EMAIL PROTECTED] time is 1058566198042
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884. 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=3884 SingleThreadModel servlets not pooled results in low performance [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-18 22:19 --- What you're using is a STM JSP, which is not the same as a servlet since its invoked through a non STM wrapper servlet: the JasperServlet. Pooling cannot be implemented in that case (unless adding a pool in the JasperServlet itself, but it would be yet another horrible hack inside Jasper, so I'm -1 for it). If you want to get the same behavior as with a regular STM servlet, you have to precompile your JSP (and map it in web.xml), in which case Catalina will identify your servlet as STM and pool it. I'm reverting to the old resolution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884. 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=3884 SingleThreadModel servlets not pooled results in low performance [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-01-08 04:45 --- Changing resolution. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884.
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=3884
SingleThreadModel servlets not pooled results in low performance
--- Additional Comments From [EMAIL PROTECTED] 2001-10-03 04:59 ---
First, let me clarify that my arguments are mainly
for the servlet SingleThreadModel interface, the JSP
'isThreadSafe=false' declaration I can do without.
It seems like you have two major arguments,
1: many users don't understand how STM works and
2: it doesn't solve any real problems.
The first one is a documentation and education problem imho.
(Maybe removing the JSP 'isThreadSafe=false' declaration
partially solves this problem. No doubt naming it 'isThreadSafe'
has contributed to the confusion.)
Note also that the assumption that there exists only one instance
of a (non-STM) servlet is broken anyway in any real world
installation using more than one web server and servlet engine.
For the second one, we have a servlet library providing different
kinds of functionality for JSPs using our product. The servlet
library is a small tree of classes. The functionality provided
consists of both methods and members. The JSPs extends a servlet
to import the wanted functionality.
SingleThreadModel is used to make this scheme work when
a servlet implements members with request specific data.
These members can be replaced with access methods, but for
all but the most trivial cases the access method now
needs to store the computed information in the request scope
instead (this is just an optimization for read-only data,
but absolutely necessary for read-write data).
Storing the data in members simplifies the code internally
but the main reason we use it is that it provides a simpler API
for our clients (implementing JSPs). Adding members adds
implicit objects that can be used directly in the JSP just as the
default implicit objects ('request', 'response', 'out' etc).
This is a much more seamless extension of a standard JSP than
possible with access methods.
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884. 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=3884 SingleThreadModel servlets not pooled results in low performance --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 09:09 --- If you (or anyone else) would like STM pooling support added, please submit a patch to make it so.
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884. 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=3884 SingleThreadModel servlets not pooled results in low performance --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 14:55 --- I'll just add a bit of text from JSDK 2.0 (a.k.a. Servlet API 2.0) in regards to SingleThreadModel: -- In essence, if the servlet implements this interface, the servlet will be thread safe. -- I have started at around that time with JServ and life was wonderful. All I needed to do was to implement SingleThreadModel and not worry about anything else ever again. Right? That's where the whole thing with SingleThreadModel is actually wrong. It gives people a false promise of something that is far more complicated than implementing one interface. Java already has threading support, no need to reinvent. After thinking about all the implications that people mentioned related to SingleThreadModel, I agree with Jon - it was a bad idea in the first place (although I didn't get it for some time Jon :-) As for pool support, let me quote JSDK 2.0 again: -- This guarantee is ensured by maintaining a pool of servlet instances for each such servlet, and dispatching each service call to a free servlet. -- And compare that to Servlet API 2.2: -- The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet. -- I think someone out there realized that the pool thing does not solve the actual problem of thread safety, complicates the code and increases the memory usage of the container, so they said: let's make it simple. It does seem like someone was sending a message to container providers, doesn't it? My point here is: I also have code relying on SingleThreadModel, and I'll have to rewrite. But I think it's time well spent.
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884. 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=3884 SingleThreadModel servlets not pooled results in low performance --- Additional Comments From [EMAIL PROTECTED] 2001-10-02 00:26 --- I would appreciate if you could explain why it is not a good idea to use SingleThreadModel (or point me to a reference explaining it). Please separate arguments against the functionality (making sure a single instance of a servlet is only used for a single request at a time, which I need) and the implementation (using implementation of an interface to declare the single thread behaviour is needed, which I don't care that much about).
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884.
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=3884
SingleThreadModel servlets not pooled results in low performance
--- Additional Comments From [EMAIL PROTECTED] 2001-10-02 08:50 ---
NOTE: Tomcat 4 *does* obey the spec requirements related to SingleThreadModel
(only one request at a time per instance). It just does not pool them.
==
The promise of SingleThreadModel, especially if you are a new developer that
is unfamiliar with multithread environments, is that you don't have to worry
about threads at all. But this is completely untrue if your application uses
sessions - it is still very easy to have multiple threads talking to the same
session at the same time. Consider some of the ways that this can happen:
* UI with multiple frames (the browser will make simultaneous requests).
* UI with dynamically created images (simultaneous requests for the same
reason that frames cause them).
* User starts a long transaction, presses STOP, then goes somewhere else.
In each case, the expectation that the developer doesn't have to worry about
threads is not met. If they don't synchronize use of their session attribute
variables appropriately, they are still going to have problems.
Ironically, pooling of SingleThreadModel instances (if it were implemented) also
violates another expectation that developers are used to in non-STM servlets -
that there is only one instance of a particular servlet per servlet
definition. In web apps, it is common to use instance variables to share
application-wide things (like connection pools and hit counters) across all
users of that servlet. But this doesn't work in an STM servlet that really is
pooled.
Further, good multithreading design patterns encourage you to minimize the need
for locking (typically implemented with synchronization in Java) - and, when you
do lock, you should lock on the smallest unit that is possible. Locking the
entire service() method, which is what STM does, is far too heavyweight. An
example of this comes from the implementation (inside Tomcat) of the HttpSession
interface, where you have methods like getAttribute() and setAttribute() that
need to lock the internal HashMap containing those attributes. However, instead
of synchronizing on the entire session object (which is similar to what STM does
on the entire servlet), the internal code locks *only* on the attributes
collection:
public void setAttribute(String name, Object value) {
...
synchronized (attributes) {
...
attributes.put(name, value);
...
}
...
}
so that no other calls to the session that are happening at the same time from
other threads (like getId() or setMaxInactiveInterval()) are affected by these
locks. This approach maximizes the concurrency - and applications should use
similar design patterns for similar reasons. Otherwise, you are needlessly
slowing down your application even if pools of STM servlets are available.
Finally, there don't seem to be any compelling use cases for SingleThreadModel
that cannot be solved using multithread design techniques -- usually, the only
thing you need to do is utilize local variables instead of instance variables
for per-request state information. So why go to the effort of teaching people
two design patterns instead of one?
I've followed mailing lists like TOMCAT-USER and SERVLET-INTEREST for several
years, and I have seen far too many developers code themselves into corners
based on mistaken assumptions about how SingleThreadModel works. I'd rather not
encourage it - but if someone wants to propose a patch to enable this, that's OK
too (as long as it complies with the spec requirements).
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
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=3884. 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=3884 SingleThreadModel servlets not pooled results in low performance --- Additional Comments From [EMAIL PROTECTED] 2001-10-01 13:40 --- Also, I get my way in JSR-053, it will be deprecated in the next servlet api release.
