You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2008/10/22 09:56:44 UTC
[jira] Created: (JS2-913) PortletFactory should not cache portlet
and application definition oid values to support live redeployment across a
cluster
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
[jira] Closed: (JS2-913) PortletFactory should not cache portlet
and application definition oid values to support live redeployment across a
cluster
Posted by "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