Raphael Luta wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Raphael Luta wrote:
> >
> > >
> > > There's a good reason why the PSML is not in the session : a PSML file is
> > > not necessarily equal to one user. The mapping between PSML files and
> > User
> > > is done by the Profiler, which can be implemented in a lot of different
> > > ways. For example, in my internal setup, I use a kind of profilied access
> > > where several users (grouped by connectivity criteria) share the same
> > PSML
> > > file. How do you efficiently handle this case when using HttpSession ?
> > >
> > > I think a more versatile strategy would be to use a FIFO or MRU cache
> > with
> > > the cache size set in the property file, just like Turbine does for its
> > > modules.
> >
> > Whether it is better to store the PSML reference in a session or in some
> > other data structure depends on the portal usage pattern. We envision a
> > usage
> > pattern where a large number of users accesses the portal mostly between 0
> > and 5 times a day; each user can have a personalized page or gets the
> > default
> > page. We expect a large percentage of users to just use the default page.
> >
> > Storing the reference to the PSML datastructure in the session is the most
> > adequate solution for this scenario, as the PSML file is only parsed once
> > per session and can be garbage collected immediately after the session
> > expires. As each user has a personal page, the PSML cannot be shared
> > between
> > users in our scenario.
> >
>
> If I understand your scenario correctly:
> - you'll never really use the cache for the personalized pages because
> your users will probably expire their sessions between requests (as
> there are few request/day expected)
If I understand it, the cache would be used, but simply it would be not scalable.
If you have, say, 10.000 users, which connect about 5 minutes a day, after a few
days, you will have 10.000 PSML wasting memory, as currently there is no
expiration mechanism. We need some kind of expiration to ensure that memory is
not being wasted in references to objects that are seldom used. But I agree that
MRU is nice. See below.
On the other side, if we stored the PSMLs in memory, we would get duplicated PSML
for the same file (be it default user or other)
>
> - you'll heavily benefit from having the default PSML always in cache.
>
> In what respect a MRU cache would *not* fit your needs ?
>
> The only disadvantage I see to the MRU is that it will use a little more
> memory under small load (because the pages will be persisted in the
> cache and not released).
> Once the MRU is full or nearly full, the behavior and cost associated to
> the MRU should be about the same that the cost associated to the session
> cache.
> Am I missing something here ?
>
No. I think a MRU solution will work fine. The admin could tune the size of the
MRU cache according to the user base, available memory and usage patterns. But it
adds complexity to the code.
I was looking for classes in Turbine implementing such a behaviour (i.e., a kind
of SingletonHolder with bounded size and MRU expiration policy), and I did not
found any service similar. Could you give me a hint? My mind is rather thick
today :-)
>
> > I understand that there are other cases, where PSML files can be shared
> > between users. Is the time consumed for parsing the PSML and generating
> > the object tree that represents it or memory usage per session the problem
> > that you see when using the session approach ?
> >
>
> My main concern about using a session cache is that we're making a usage
> pattern asssumption which may not be true in some installations. I'd like
> the portal engine to be agnostic to usage pattern. Optimization for a given
> pattern should be handled at a pluggable component level.
>
> The Profiler component is currently responible for implementing the usage
> pattern, maybe we can add methods to the Profiler API to allow a profiler
> to provide caching hints for a cache system ?
>
If we could stick to java 2, we could use a SoftReference (or whatever kind of
reference) in the PortletSetFactory, so that when memory is low and there are no
other reference dangling, the unreferenced PSMLs can be collected. Unfortunately,
these classes do not exist in java 1.1, because the code changes in this case
would be trivial.
>
>
> --
> Rapha�l Luta - [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
