portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From raphael.l...@networks.groupvu.com
Subject Re: Portlet Caching problem
Date Tue, 02 Apr 2002 08:30:05 GMT
[warning, ramblings ahead...]

First, Glenn you're completely right the Portlet caching as currently
implemented in Jetspeed is screwed up.
Second, there is an incoherence between Portlet/PortletConfig and PSML that
is mainly legacy based :
when Kevin started Jetspeed there was no PSML and the the PortletConfig was how
Jetspeed stored its portlet parameters and caching was applied on Portlet
+ PortletConfig; when I added PSML support I could not remove the PortletConfig at
the time so we end up creating objects like this:

PSML file ---> PSML Entry objects --------------> Portlet + PortletConfig
                                        ^
	                        PortletSetFactory

which neither very clean design, nor very efficient.

In fact now that David has completed the move of the PSML implementation to an
interface based API, PortletConfig is truly completely redundant and *should*
be replaced directly by a org.apache.jetspeed.om.profile.Entry implementation.

Caching:
--------
Caching is necessary for 2 reasons:
- avoid expensive convertion cycles from Entry -> PortletConfig
   (PortletFactoryService)
   This can simply be achieved by removing PortletConfig altogether and using
   directly an Entry associated to a Portlet.
- prevent unnecessary instanciation of Portlet objects, this can be solved
   using a pool of objects that can be grabbed, associated to a state, executed
   & released (Turbine PoolService may be used for this purpose).

Now for this to be effective, it's critical that Portlet instances are not cached
within a user session else we can't release this object to the pool without making
the session incoherent.
Especially, use of PortletSet should be carefully monitored because this Portlet
instance stores a vector of Portlet objects...
(PortletSet is yet another evil interface created to circumvent a shortcoming
  of the initial interface, it should be deprecated and replaced by
  org.apache.jetspeed.om.profile.Portlets instances.)

In fact caching is going to keep being a huge mess unless there's a proper
separation of concerns between the "Portlet" API and the "PSML/Profile" API:

If we can move all the data stateful information to the Profile API,
these objects can be properly cached in a user/shared/global data cache as
appropriate whereas the Portlet API can be moved to a pool-based caching
mechanism since these Portlet would only be executed and would not store any
user data.

At this stage, you only need to remove :
Portlet.getPortletConfig()
and add
Portlet.getContent(Rundata,Entry)

to have a servlet like Portlet object model and be very close to the new JSR API,
at least conceptually because they certainly aren't going to keep Rundata in the
top level Portlet API (yet another design issue with the current Jetspeed).

I hope this made sense at least in some parts. ;)

Glenn Golden wrote:
>>-----Original Message-----
>>From: David Sean Taylor [mailto:david@bluesunrise.com] 
>>Sent: Monday, April 01, 2002 11:34 PM
>>To: 'Jetspeed Developers List'
>>Subject: RE: Portlet Caching problem
> 
> 
>>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.
> 
> 
> What do you mean by getInstance() here? I don't see it in
> org.apache.jetspeed.portal.Portlet now...
> 
> I've been thinking about the relationship between the Entry (from the psml
> file, an om? Peer? Class) and Portlet... If the Profiler loaded docs in such
> as way as to make the Entrys available, then instead of copying the Entry
> info into the Portlet, we could so some pointing...
> 
> I think we need to carefully look at / rethink the three services: Profiles,
> JetspeedPortletFactoryService, and JetspeedPortalToolkitService.  Profiler
> provides the psml doc, tooklit service creates a portlet set, and uses the
> factory and its caching to get Portlet objects.
> 
> * * *
> 
> My tests tonight confirm that the caching is improperly (as far as peid and
> meta is concerned) reusing Portlet objects, and that if the portal page +
> peid is made part of the cache handle, this reuse stops.  This may be more
> severe than we want, and a re-org of the three services involved may produce
> a much more efficient and correct situation.
> 
> Also noticed that the PortletWrapper objects are not cached, and are being
> created and used once and thrown away for each wrapped portlet.  Messy.
> 
> - 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/
> --------------------------------------------
> 
>  
> 
> --
> To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 



-- 
Raphael Luta - raphael.luta@networks.groupvu.com
Professional Services Manager
Vivendi Universal Networks - Paris


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