[jira] Closed: (JS2-913) PortletFactory should not cache portlet and application definition oid values to support live redeployment across a cluster

["Ate Douma (JIRA)" <je...@portals.apache.org>]

     [ https://issues.apache.org/jira/browse/JS2-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma closed JS2-913.
-------------------------

    Resolution: Fixed

Fix applied to 4 svn trees: the trunk and branches 2.1.2-postrelease, 2.1.3-postrelease and JS2-871-pluto-2.0-upgrade (done by David Taylor also merging in other changes).

> PortletFactory should not cache portlet and application definition oid values to support live redeployment across a cluster 
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JS2-913
>                 URL: https://issues.apache.org/jira/browse/JS2-913
>             Project: Jetspeed 2
>          Issue Type: Improvement
>          Components: Portlet Factory
>    Affects Versions: 2.1.2, 2.1.3, 2.2
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.2-M1, 2.2
>
>
> The current implementation of the PortletFactory maintains internal caches for lookup of PortletApplication and Portlet definition references (e.g. classloader and validator).
> This poses a problem on clustered environments when a live redeployment is performed across a cluster setup.
> Such a redeployment *might* cause reregistration of a PortletApplication causing the internal oid values to change.
> On the node where this deployment is performed, this is not causing any problems as the application will first also reregister with the PortletFactory, but other nodes *not yet updated* can become out of sync temporarily.
> In that case, the PortletFactory on those other nodes can throw an UnavailableException as their internal oids won't match up anymore.
> The solution is to *not* use the oid values anymore, but only use cache keys using the public unique name values of both the PortletApplication and the Portlet as those should remain stable,
> unless a portlet is actually dropped by a redeployment, but then that Portlet logically truly should be marked as Unavailable anyway. 
> BTW: for Jetspeed 2.2, we're going to remove the public access to the internal oids as much as possible (if possible: 100%) to prevent potentially similar problems in other areas as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org