portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Closed: (JS2-913) PortletFactory should not cache portlet and application definition oid values to support live redeployment across a cluster
Date Wed, 22 Oct 2008 20:25:44 GMT

     [ 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


Mime
View raw message