[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.
It is very funny. Yesterday, at about 18h CET time, Juan Carlos and I were
discussing in my office exactly the same issues.
That confirms that parallel design and development in OSS does not optimize
resource usage, but rather it is a "brute force" approach that simply get
things done in a context where communications are cheap and long lived (
tracked in the lists )... while the cathedral style was THE way when
communications were expensive and did not propagate efficiently out of small
groups due to its verbal nature.
>
> 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.
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?
Rephrasing the desing problem: Would you prefer that an anonymous user will be
able to customise the site, with customisations lost after s/he logs out (or
after a long term cookie expires), or else that the edit ... buttons are
disabled?
I think that having no special cases is simpler, even if slightly less
efficient in new session buiding, and brings the benefit that we could have
persistent anonymous sessions, tracked by cookies. So, the system can remind
you, provided that you always come from the same machine, and you can edit and
save your PSML.
This will require that expired sessions are stored in database, having a
special cookie value as the id, to be recovered later when the user comes back.
This would allow to have two kind of sessions:
- New sessions (Current default user)
- Anonymous sessions (The system remembers you, even if it does not know who
you are. It requires checking for a cookie, retrieving the persistent data, and
storing the cookie back. You would have the default user rights, with your
customisations to content and layout. If you log in from a different machine,
you are a new user and your psml is not restored.)
- User sessions (The system remembers you, knowing extra data about you. You
can log in from different machines and have your preferences restored.)
Thoughts or preferences on this?
>
> 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]
--
--------------------------------------------------------------
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]
