portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Portlet Caching problem
Date Tue, 02 Apr 2002 03:24:52 GMT
Even for RSS portlets... The way it's coded now, the same portlet object
will be used, cached, for each instance of the RSS portlet (with the
specific url, params, etc).

Good, as the set of portlet instances all have the 'feed' in common.

Bad, as each portlet instance has it's own PEID.

The way it's coded now (in JetspeedPortalToolkitService.getSet()), it finds
a cached portlet object, then messes with that object's id (and the
JetspeedPortletFactoryService messes with the portlet's title and
description).  This is on the cached object!  What good is caching it if we
are going to mess with it?

If we only needed one of these objects at a time, then the messing would be
ok - we update the cached object, use it, and next time update it again for
the next use.  But we are using many of the same object at once to do a
single portal page (if the portlet is on there many times), and many objects
at once to handle multiple concurrent requests from different pages (if the
portlet is on many pages).

It just doesn't work!  The PEID coded into the control buttons will be
wrong.  The title and description will be wrong.

I'm getting some ideas about how to fix this... But I'm not so confident
(yet) on this code base... So any help with verifying my concerns here will
be appreciated!

- Glenn 
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu               734-615-1419


> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com] 
> Sent: Monday, April 01, 2002 9:58 PM
> To: 'Jetspeed Developers List'
> Subject: RE: Portlet Caching problem
> Please consider that RSS portlets do want to be shared across 
> multiple users and instances. With anytype of content feed in 
> general or shared resource, we don't want content per 
> instance. Thus, the default mode of portlet caching *must* 
> work exactly as it works now for backward compatibility. Not 
> to mention having multitudes of un-necessary RSS feeds in memory.
> I've added several parameters recently to the registry to aid in
> caching:
> 	org.apache.jetspeed.om.registry.CachedParameter.isCachedOnName
> 	org.apache.jetspeed.om.registry.CachedParameter.isCachedOnValue
> 	org.apache.jetspeed.om.registry.ContentURL.isCachedOnURL()
> By default they are all set to true - so that we don't screw 
> up shared resources (RSS).
> isCachedOnURL() is the only functional parameter right now. 
> The other two will require refactoring of PortletConfig which 
> looks a bit messy.
> If you want your portlet to be cached based on the psml-id + 
> id, simply override the getHandle() in your portlet class or 
> some base class. But please do not change AbstractPortlet's 
> default behavior.
> > 
> > When any of this information changes, due to a re-load of the
> > registry, or a customization of the portlet on the page, we 
> > must invalidate this object from the cache!
> > 
> Yes, when you reload a portlet from the registry, I would hope that it
> gets expired.
> Are you saying that it doesn't?
> > Two of the same portlets on the same page need to have 
> > different Portal objects (these have different peids, at 
> > least, and maybe different psml parameters).
> > 
> > Two of the same portlets on different portal pages need to 
> > have different Portal objects as well, for the same reason.
> > 
> > A cached Portlet object could be reused for subsequent page 
> > requests, and for page requests from other users viewing the 
> > same page.  And only this - any other use of the portlet 
> > would be a different portlet instance and need a different 
> > Portlet object.
> > 
> > So, a good handle for caching of one of these Portlet objects 
> > would be the portlet's PEID, plus the portal page's unique 
> > id.  The parameters don't matter, nor does the ancestry or 
> > meta information, nor does the portlet class.
> > 
> > I'll start making this change, if I hear a positive sanity 
> > check from the developers.
> > 
> Please don't change AbstractPortlet.
> Why not change getHandle in VelocityPortlet or come up with a 
> new class
> hierachy:
> SharedPortlet          InstancePortlet
> > Do we have anything from a portal page (or from the root 
> > portlet set element in a page) that can be used for a unique 
> > portal page id?  I need it for this (and other purposes!).  
> > The file name is ok, but probably won't work for database 
> Don't use the filename, it doesn't work with the DB version and is not
> normalized.
> The profiler, given a profile, can easily generate a standard, unique
> string identifying the page in a format such as:
>    /group/<group_name>   - no default group_name
>    /role/<role_name>     - no default role_name
>    /user/<user_name>     - defaults to the current user
>    /page/<page_name>     - defaults to /page/default (or what ever is
>                            configured in JR.p
>    /js_pane/<peid>       - Can not be used with /js_pane
>                            Defaults to the root element (pane or
> portlet)
>    /js_peid/<peid>       - Can not be used with /js_peid
>                            Defaults to the root element (pane or
> portlet)
>    /action/<action_name> - no default action_name
> I believ Paul was working on this for the JetspeedTemplateLink. 
> > versions... Do we need to add a new PEID for this at the 
> portal level?
> See 
> Org.apache.jetspeed.om.profile.psml.PsmlPortlets is an 
> IdentityElement,
> i.e. it has an ID.
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message