You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Leon Rosenberg <le...@friendscout24.de> on 2005/09/07 00:04:57 UTC
How ThreadSafe are struts-taglibs, or do we want them threadsafe?
I just looked through 1.27 and 1.3 taglibs, and they aren't threadsafe, or I
don't see it.
Question:
Is it my personal issue, or is someone else worried that bean:write can hang
the application?
regards
Leon
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/7/05, Leon Rosenberg <le...@friendscout24.de> wrote:
>
> I submitted the bug (36541) to ASF bugzilla. Lets see what tomcat people
> gonna say about it :-)
The answer was hardly surprising :-(. Adding a pointer to this bug report to
the info sent to the Servlet spec lead.
In the mean time, it's time to think about using a container whose
developers care about protecting users from this issue more than they care
about minimizing runtime overhead.
regards
> Leon
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: How ThreadSafe are struts-taglibs, or do we want them
threadsafe?
Posted by Leon Rosenberg <le...@friendscout24.de>.
On Tue, 2005-09-06 at 18:28 -0700, Craig McClanahan wrote:
> On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
> >
> >
> >
> > After we agreed that this is a bug, I have to disappoint you again, and
> > tell
> > you, that this is NOT a bug.
> > According to the servlet spec, the webapp has to control access to the
> > session, not the container. To quote the jdk1.4 tutorial:
> > (http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html, chapter 11)
>
>
>
> Forwarded a note to the servlet spec lead ... the underlying spec language (
> SRV.7.7.1) was originally intended to remind application users that they
> must make their *own* objects threadsafe if they are stored as a session
> attribute. To use that language as an excuse for the *container* not having
> to make its own collections threadsafe means that the language is broken.
>
> Craig
I submitted the bug (36541) to ASF bugzilla. Lets see what tomcat people
gonna say about it :-)
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
>
>
>
> After we agreed that this is a bug, I have to disappoint you again, and
> tell
> you, that this is NOT a bug.
> According to the servlet spec, the webapp has to control access to the
> session, not the container. To quote the jdk1.4 tutorial:
> (http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html, chapter 11)
Forwarded a note to the servlet spec lead ... the underlying spec language (
SRV.7.7.1) was originally intended to remind application users that they
must make their *own* objects threadsafe if they are stored as a session
attribute. To use that language as an excuse for the *container* not having
to make its own collections threadsafe means that the language is broken.
Craig
Re: How ThreadSafe are struts-taglibs, or do we want them
threadsafe?
Posted by Joe Germuska <Jo...@Germuska.com>.
Leon:
It's interesting what you've found in the docs, but I fail to see how
it can be the application's responsibility to manage concurrent
access to the session. I think maybe this text is intended to assign
responsibility for non-container shared resources. Since it is
possible for more than one servlet to concurrently service requests
for a single session-holder, Struts itself simply can't intercede to
guarantee that all access to the session is thread-safe. Imagine
simply a frameset which has several JSPs (each its own servlet,
remember), each of which is perhaps doing a little more that is
considered good practice in a JSP and attempting to modify the
session.
I would bet money that the authors of the text you quote are
intending to warn about access to shared resources that you design
yourself: things you may place in the session or application context,
but not those contexts themselves.
Joe
>Controlling Concurrent Access to Shared Resources
>
>In a multithreaded server, it is possible for shared resources to be
>accessed concurrently. In addition to scope object attributes, shared
>resources include in-memory data (such as instance or class variables) and
>external objects such as files, database connections, and network
>connections. Concurrent access can arise in several situations:
>...
>
>When resources can be accessed concurrently, they can be used in an
>inconsistent fashion. To prevent this, you must control the access using the
>synchronization techniques described in the Threads lesson in The Java
>Tutorial, by Mary Campione et al. (Addison-Wesley, 2000).
>
>
>The point is:
>To prevent this, _YOU_ must control the access using the synchronization
>techniques
>
>
>And in this case "YOU" is struts. At least struts could do it. At least
>optional.
>Sure, it will not give you 100% guarantee, but if struts would provide
>methods for thread-safe session handling and be thread-safe itself, wouldn't
>it be lot easier for the users to code thread-safe webapps?
>
>
>Regards
>Leon
>
>P.S. If you say NO again, I will not spam you with this topic anymore.
>Promised :-)
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Leon Rosenberg <le...@friendscout24.de>.
> -----Ursprüngliche Nachricht-----
> Von: Craig McClanahan [mailto:craigmcc@gmail.com]
> Gesendet: Mittwoch, 7. September 2005 01:38
> An: Struts Developers List
> Betreff: Re: How ThreadSafe are struts-taglibs, or do we want
> them threadsafe?
>
> On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
> >
> >
> > Sorry Graig, I looked into the source; yes, it has your name in it,
> > and no, it is not thread safe (jakarta-tomcat-5.0.25-src)
>
>
> Looks like they did change it. Go look at the corresponding
> code in 4.1 to see what I was talking about :-).
>
> [snip]
>
> >
> > Ok, other suggestion, lets talk to the tomcat people, that they fix
> > the bug, or at least add a party synchronized version of
> > add/get/remove attribute.
>
>
> That's the right answer ... or, more precisely, start by
> filing a bug against it (http://issues.apache.org/bugzilla).
>
After we agreed that this is a bug, I have to disappoint you again, and tell
you, that this is NOT a bug.
According to the servlet spec, the webapp has to control access to the
session, not the container. To quote the jdk1.4 tutorial:
(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html, chapter 11)
Controlling Concurrent Access to Shared Resources
In a multithreaded server, it is possible for shared resources to be
accessed concurrently. In addition to scope object attributes, shared
resources include in-memory data (such as instance or class variables) and
external objects such as files, database connections, and network
connections. Concurrent access can arise in several situations:
...
When resources can be accessed concurrently, they can be used in an
inconsistent fashion. To prevent this, you must control the access using the
synchronization techniques described in the Threads lesson in The Java
Tutorial, by Mary Campione et al. (Addison-Wesley, 2000).
The point is:
To prevent this, _YOU_ must control the access using the synchronization
techniques
And in this case "YOU" is struts. At least struts could do it. At least
optional.
Sure, it will not give you 100% guarantee, but if struts would provide
methods for thread-safe session handling and be thread-safe itself, wouldn't
it be lot easier for the users to code thread-safe webapps?
Regards
Leon
P.S. If you say NO again, I will not spam you with this topic anymore.
Promised :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
>
>
> Sorry Graig, I looked into the source; yes, it has your name in it, and
> no,
> it is not thread safe (jakarta-tomcat-5.0.25-src)
Looks like they did change it. Go look at the corresponding code in 4.1 to
see what I was talking about :-).
[snip]
>
> Ok, other suggestion, lets talk to the tomcat people, that they fix the
> bug,
> or at least add a party synchronized version of add/get/remove attribute.
That's the right answer ... or, more precisely, start by filing a bug
against it (http://issues.apache.org/bugzilla).
Leon
Craig
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Leon Rosenberg <le...@friendscout24.de>.
> -----Ursprüngliche Nachricht-----
> Von: Craig McClanahan [mailto:craigmcc@gmail.com]
> Gesendet: Mittwoch, 7. September 2005 00:59
> An: Struts Developers List
> Betreff: Re: How ThreadSafe are struts-taglibs, or do we want
> them threadsafe?
>
...
> When I was working on Tomcat a couple years ago , I can vouch
> for the fact that it did this correctly. I haven't looked at
> the latest version's sources, but I can't imagine they would
> have broken this -- it's too fundamental.
>
Sorry Graig, I looked into the source; yes, it has your name in it, and no,
it is not thread safe (jakarta-tomcat-5.0.25-src)
class org.apache.catalina.session.StandardSession
...
* @author Craig R. McClanahan
* @author Sean Legassick
* @author <a href="mailto:jon@latchkey.com">Jon S. Stevens</a>
* @version $Revision: 1.43 $ $Date: 2004/04/01 20:18:15 $
...
public class StandardSession
implements HttpSession, Session, Serializable {
...
/**
* The collection of user data attributes associated with this Session.
*/
protected HashMap attributes = new HashMap();
...
public void setAttribute(String name, Object value) {
...
// Replace or add this attribute
Object unbound = attributes.put(name, value);
...
}
...
public Object getAttribute(String name) {
if (!isValid())
throw new IllegalStateException
(sm.getString("standardSession.getAttribute.ise"));
return (attributes.get(name));
}
It is using HashMap, and the HashMap isn't synchronized, nor it is
threadsafe. Neither the StandardSession nor the Facade are synchronizing
anything or protect the underlying HashMap from parallel modification.
What actually happens, if you write to the Session (and therefor into the
HashMap) simultaneously in multiple threads, you get to the point where you
have a HashMap whose entries got circularly linked, and any thread using a
get() on such a HashMap will spin forever chasing its tail (quoted from
Larry Isaacs).
If you have any other explanation why this threads hangs in this method for
an hour, go on:
"http-8580-Processor3" daemon prio=1 tid=0x7cdf11d0 nid=0x3269 runnable
[7d7fe000..7d7ff8bc]
at java.util.HashMap.get(HashMap.java:325)
at
org.apache.catalina.session.StandardSession.getAttribute(StandardSession.jav
a:975)
at
org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessi
onFacade.java:109)
...
> Sure, struts can't save you from this, but struts could give
> you tools to
> > right cleaner webapps. And it would be 20 lines of code.
>
>
> Adding this to Struts would be:
>
> * Making applications *less* clean rather than more, because
> they would be adding a layer of complexity around an existing
> function provided by the platform APIs, without any
> corresponding improvement in ease of use to compensate.
>
> * Creating needless runtime overhead on containers that do
> not fail to handle get/set attribute safely.
>
> * Providing a false promise that using the utility methods
> protects you from this flaw in the container. It can't
> provide that guarantee.
Ok, other suggestion, lets talk to the tomcat people, that they fix the bug,
or at least add a party synchronized version of add/get/remove attribute.
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
>
> > If your servlet container has a broken implementation of
> > get/set attributes on an HttpSession, there is nothing that
> > Struts can do to protect you from problems ... even providing
> > synchronized locks around get/set calls would still not avoid
> > problems caused by application logic, or logic inside the
> > container itself, that would bypass it.
> >
> > Sounds like you need to get after the folks providing your
> > container to fix this.
>
> since the Servlet spec leaves it up to the webapp to implement thread safe
> setting and update of session objects I don't think I will find a safe
> container out there :-(
When I was working on Tomcat a couple years ago , I can vouch for the fact
that it did this correctly. I haven't looked at the latest version's
sources, but I can't imagine they would have broken this -- it's too
fundamental.
Sure, struts can't save you from this, but struts could give you tools to
> right cleaner webapps. And it would be 20 lines of code.
Adding this to Struts would be:
* Making applications *less* clean rather than more, because
they would be adding a layer of complexity around an existing
function provided by the platform APIs, without any corresponding
improvement in ease of use to compensate.
* Creating needless runtime overhead on containers that do not
fail to handle get/set attribute safely.
* Providing a false promise that using the utility methods protects
you from this flaw in the container. It can't provide that guarantee.
Regards
> Leon
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Leon Rosenberg <le...@friendscout24.de>.
> If your servlet container has a broken implementation of
> get/set attributes on an HttpSession, there is nothing that
> Struts can do to protect you from problems ... even providing
> synchronized locks around get/set calls would still not avoid
> problems caused by application logic, or logic inside the
> container itself, that would bypass it.
>
> Sounds like you need to get after the folks providing your
> container to fix this.
since the Servlet spec leaves it up to the webapp to implement thread safe
setting and update of session objects I don't think I will find a safe
container out there :-(
Sure, struts can't save you from this, but struts could give you tools to
right cleaner webapps. And it would be 20 lines of code.
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
>
> Heh :-)
>
> It explains some ugly side-effects I've seen from time to time in last
> years
> with struts, but never bothered to investigate.
> However, we actually do have application hang-ups because of
> thread-unsafity
> of session.getAttribute() / session.setAttribute().
> It also seem possible to hang a webapp (not our:-)) just by hitting f5
> (reload) quick enough.
> I understand that this is a tomcat (or JSP Spec) issue, rather than
> struts,
> but struts could at least provide thread-safe methods for attribute
> handling
> in actions and taglibs (and it would be about 20 lines of code...).
If your servlet container has a broken implementation of get/set attributes
on an HttpSession, there is nothing that Struts can do to protect you from
problems ... even providing synchronized locks around get/set calls would
still not avoid problems caused by application logic, or logic inside the
container itself, that would bypass it.
Sounds like you need to get after the folks providing your container to fix
this.
Regards
> Leon
Craig
> -----Ursprüngliche Nachricht-----
> > Von: Martin Cooper [mailto:mfncooper@gmail.com]
> > Gesendet: Mittwoch, 7. September 2005 00:16
> > An: Struts Developers List
> > Betreff: Re: How ThreadSafe are struts-taglibs, or do we want
> > them threadsafe?
> >
> > On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
> > >
> > > I just looked through 1.27 and 1.3 taglibs, and they aren't
> > > threadsafe, or I don't see it.
> > >
> > > Question:
> > > Is it my personal issue, or is someone else worried that bean:write
> > > can hang the application?
> >
> >
> > Or is there really a problem? ;-) It's been the way it is for
> > about 5 years now, and I don't recall a bug submitted against
> > this before. But we'd definitely like to know about it if
> > there really is a problem.
> >
> > --
> > Martin Cooper
> >
> >
> > regards
> > > Leon
> > >
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Leon Rosenberg <le...@friendscout24.de>.
Heh :-)
It explains some ugly side-effects I've seen from time to time in last years
with struts, but never bothered to investigate.
However, we actually do have application hang-ups because of thread-unsafity
of session.getAttribute() / session.setAttribute().
It also seem possible to hang a webapp (not our:-)) just by hitting f5
(reload) quick enough.
I understand that this is a tomcat (or JSP Spec) issue, rather than struts,
but struts could at least provide thread-safe methods for attribute handling
in actions and taglibs (and it would be about 20 lines of code...).
Regards
Leon
> -----Ursprüngliche Nachricht-----
> Von: Martin Cooper [mailto:mfncooper@gmail.com]
> Gesendet: Mittwoch, 7. September 2005 00:16
> An: Struts Developers List
> Betreff: Re: How ThreadSafe are struts-taglibs, or do we want
> them threadsafe?
>
> On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
> >
> > I just looked through 1.27 and 1.3 taglibs, and they aren't
> > threadsafe, or I don't see it.
> >
> > Question:
> > Is it my personal issue, or is someone else worried that bean:write
> > can hang the application?
>
>
> Or is there really a problem? ;-) It's been the way it is for
> about 5 years now, and I don't recall a bug submitted against
> this before. But we'd definitely like to know about it if
> there really is a problem.
>
> --
> Martin Cooper
>
>
> regards
> > Leon
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How ThreadSafe are struts-taglibs, or do we want them threadsafe?
Posted by Martin Cooper <mf...@gmail.com>.
On 9/6/05, Leon Rosenberg <le...@friendscout24.de> wrote:
>
> I just looked through 1.27 and 1.3 taglibs, and they aren't threadsafe, or
> I
> don't see it.
>
> Question:
> Is it my personal issue, or is someone else worried that bean:write can
> hang
> the application?
Or is there really a problem? ;-) It's been the way it is for about 5 years
now, and I don't recall a bug submitted against this before. But we'd
definitely like to know about it if there really is a problem.
--
Martin Cooper
regards
> Leon
>
>
>