Raphael Luta wrote:
> Santiago Gala wrote:
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > There seems to be a scalability problem in the PortletSetFactory:
> > > For each user, a PortletSetFactory object is created that holds a
> > > Portlets tree representing the user's PSML file. I guess the tree
> > > can become quite big in terms of memory usage.
> > >
> > > The PortletSetFactory object is stored in the SingletonHolder and
> > > apparently is never removed. If the number of users is large, the
> > > memory of the server may be used up after running for some time.
> > >
> > > Is there a particular reason for not putting the PortletSetFactory
> > > object into the HttpSession ?
> > > This would allow the JVM to garbage-collect the PortletSetFactory
> > > and the referenced Portlets tree after the HTTP session expires.
> > >
> >
> > That were exactly the final conclussion we reached. For a small portal
> > with a small number of users, it does not matter. If you are developing
> > a portal with hundreds of thousands of users, it is better to have in
> > memory only the PSMLs from the users that have active sessions, and
> > reparse the file when the user logs in again, than having tens of
> > thousands of dangling psml trees in memory after your portal has been
> > up for a couple of months.
> >
> > We will put this as a proposal, it nobody oposes. I'm clearly +1 on
that.
> >
> > So the PortletSetFactory will disappear, and the user PSML will be
> > retrieved from the session if it is there, or else created and put
> > there when the session starts or the user logs in.
> >
>
> 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.
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 ?
> > CAVEAT: There is an exception for the default user PSML, maybe, but is
> > could be stored in a static var in the PortletSet class, from where it
> > could be copied by a special method, if it is not writable. If we want
> > to modify it, then the default.psml should be recreated by every
"default"
> > session. Ideas on this?
>
> I don't think any file should be treated in a specific way. The
PortletFactory
> has *no way* to guess the use (authenticated/anonymous/something else)
ofa
> given PSML file, this is all handled by the Profiler.
>
> I would be -1 on any tie between PSML and a user session.
>
> --
> Rapha�l Luta - [EMAIL PROTECTED]
>
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--------------------------------------------------------------
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]
