You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Wayne Holder (JIRA)" <pl...@jakarta.apache.org> on 2005/02/04 19:40:26 UTC
[jira] Created: (PLUTO-106) PortletServlet does not follow the servlet API
PortletServlet does not follow the servlet API
----------------------------------------------
Key: PLUTO-106
URL: http://issues.apache.org/jira/browse/PLUTO-106
Project: Pluto
Type: Bug
Components: portlet container
Versions: 1.0.1-rc2
Environment: All
Reporter: Wayne Holder
>From inspection, it appears that PortletServlet is not thread safe and, in fact, is coded in a way that completely violates the requirements of the servlet life cycle. As stated in SRV.2.2: "For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration." In practical terms, this means that one must not code a servlet in a way that assumes instance variables can be used to pass information from one method to another because multiple threads from simultaneous requests will overwrite each other's data, resulting in erratic behavior. Yet, that's exactly how PortletServlet is coded. In particular, the class declares tbese instance variables:
private boolean portletInitialized = false;
private Portlet portletClass = null;
and then assumes it can set them in the init(ServletConfig) and that they will stay valid until PortletServlet's dispatch() method is called. While this may appear to work in cases where only simple tests are being run, it's not correct and will act in unpredictable ways under real-world conditions.
The cheap way out of this gotcha is to change the declaration of PortletServlet to implement the SingleThreadModel interface, as this will force the servlet container to guarantee that only one thread calls PortletServlet at any given time. Of course, this is a kludge, and should be avoided from a performance standpoint, but it's at least avoid the potential twilight zone behavior of the current code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (PLUTO-106) PortletServlet does not follow the servlet API
Posted by "David DeWolf (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-106?page=history ]
David DeWolf closed PLUTO-106:
------------------------------
Resolution: Invalid
> PortletServlet does not follow the servlet API
> ----------------------------------------------
>
> Key: PLUTO-106
> URL: http://issues.apache.org/jira/browse/PLUTO-106
> Project: Pluto
> Type: Bug
> Components: portlet container
> Versions: 1.0.1-rc2
> Environment: All
> Reporter: Wayne Holder
>
> From inspection, it appears that PortletServlet is not thread safe and, in fact, is coded in a way that completely violates the requirements of the servlet life cycle. As stated in SRV.2.2: "For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration." In practical terms, this means that one must not code a servlet in a way that assumes instance variables can be used to pass information from one method to another because multiple threads from simultaneous requests will overwrite each other's data, resulting in erratic behavior. Yet, that's exactly how PortletServlet is coded. In particular, the class declares tbese instance variables:
> private boolean portletInitialized = false;
> private Portlet portletClass = null;
> and then assumes it can set them in the init(ServletConfig) and that they will stay valid until PortletServlet's dispatch() method is called. While this may appear to work in cases where only simple tests are being run, it's not correct and will act in unpredictable ways under real-world conditions.
> The cheap way out of this gotcha is to change the declaration of PortletServlet to implement the SingleThreadModel interface, as this will force the servlet container to guarantee that only one thread calls PortletServlet at any given time. Of course, this is a kludge, and should be avoided from a performance standpoint, but it's at least avoid the potential twilight zone behavior of the current code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-106) PortletServlet does not follow the servlet API
Posted by "Brett Randall (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-106?page=comments#action_58664 ]
Brett Randall commented on PLUTO-106:
-------------------------------------
These instance variables are fine and are used in an appropriate fashion, as they are set in init() and are not updated by servlet service methods, so they are completely thread-safe.
I can't see any possibility for twilight zone behaviour in the current code - can you elaborate, perhaps provide a test-case? SingleThreadModel should be avoided at all costs (deprecated in 2.4 spec).
I was a little confused though by the requirement for portletInitialized and its reference to <load-on-startup> :
if (!portletInitialized)
{
throw new ServletException("this portlet uses the <load-on-startup> flag. You have to turn it off");
}
... does this mean that someone has found a container that permits service methods prior to init() completing, or have I missed something?
> PortletServlet does not follow the servlet API
> ----------------------------------------------
>
> Key: PLUTO-106
> URL: http://issues.apache.org/jira/browse/PLUTO-106
> Project: Pluto
> Type: Bug
> Components: portlet container
> Versions: 1.0.1-rc2
> Environment: All
> Reporter: Wayne Holder
>
> From inspection, it appears that PortletServlet is not thread safe and, in fact, is coded in a way that completely violates the requirements of the servlet life cycle. As stated in SRV.2.2: "For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration." In practical terms, this means that one must not code a servlet in a way that assumes instance variables can be used to pass information from one method to another because multiple threads from simultaneous requests will overwrite each other's data, resulting in erratic behavior. Yet, that's exactly how PortletServlet is coded. In particular, the class declares tbese instance variables:
> private boolean portletInitialized = false;
> private Portlet portletClass = null;
> and then assumes it can set them in the init(ServletConfig) and that they will stay valid until PortletServlet's dispatch() method is called. While this may appear to work in cases where only simple tests are being run, it's not correct and will act in unpredictable ways under real-world conditions.
> The cheap way out of this gotcha is to change the declaration of PortletServlet to implement the SingleThreadModel interface, as this will force the servlet container to guarantee that only one thread calls PortletServlet at any given time. Of course, this is a kludge, and should be avoided from a performance standpoint, but it's at least avoid the potential twilight zone behavior of the current code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-106) PortletServlet does not follow the servlet API
Posted by "Wayne Holder (JIRA)" <pl...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-106?page=comments#action_58680 ]
Wayne Holder commented on PLUTO-106:
------------------------------------
Please mark this up as faulty analysis on my part. On further review, the code looks fine. Sorry for the confusion.
> PortletServlet does not follow the servlet API
> ----------------------------------------------
>
> Key: PLUTO-106
> URL: http://issues.apache.org/jira/browse/PLUTO-106
> Project: Pluto
> Type: Bug
> Components: portlet container
> Versions: 1.0.1-rc2
> Environment: All
> Reporter: Wayne Holder
>
> From inspection, it appears that PortletServlet is not thread safe and, in fact, is coded in a way that completely violates the requirements of the servlet life cycle. As stated in SRV.2.2: "For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration." In practical terms, this means that one must not code a servlet in a way that assumes instance variables can be used to pass information from one method to another because multiple threads from simultaneous requests will overwrite each other's data, resulting in erratic behavior. Yet, that's exactly how PortletServlet is coded. In particular, the class declares tbese instance variables:
> private boolean portletInitialized = false;
> private Portlet portletClass = null;
> and then assumes it can set them in the init(ServletConfig) and that they will stay valid until PortletServlet's dispatch() method is called. While this may appear to work in cases where only simple tests are being run, it's not correct and will act in unpredictable ways under real-world conditions.
> The cheap way out of this gotcha is to change the declaration of PortletServlet to implement the SingleThreadModel interface, as this will force the servlet container to guarantee that only one thread calls PortletServlet at any given time. Of course, this is a kludge, and should be avoided from a performance standpoint, but it's at least avoid the potential twilight zone behavior of the current code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira