portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Portlet Caching problem
Date Tue, 02 Apr 2002 04:34:08 GMT
See comments below

> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Monday, April 01, 2002 7:25 PM
> To: 'Jetspeed Developers List'
> Subject: RE: Portlet Caching problem
> 
> 
> 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.
> 

That is a problem. 
Ive often noticed my titles mysteriously changed, never could figure it
out.

Portlet.getID() should always delegate to its portlet instance.
Perhaps it should be Portlet.getInstance().getId() and deprecate
Portlet.getID()  
Same goes for title and description.
Although the title and description should be able to fallback to the
Configuration meta info.
I believe that is what is attempted via PortletConfig.

This comment from JetspeedPortalToolkitService.getSet() looks suspicious
:)

        //FIXME: this sucks ! we should either associate the portlet set
        //with its portlets peer or set the porpoerties directly on the
portlet
        //set object
        //Unfortunately, this would change the API too drastically for
now...
        set.setPortletConfig( getPortletConfig( portlets ) );

> 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!

Lets take our time with this. I should have some overlap on this problem
this week.

> 
> - Glenn 
>  
> --------------------------------------------
> Glenn R. Golden, Systems Research Programmer
> University of Michigan School of Information
> ggolden@umich.edu               734-615-1419
> http://www-personal.si.umich.edu/~ggolden/
> --------------------------------------------
> 
>  
> 
> > -----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>
> 
> 



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


Mime
View raw message