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.
>
> 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.
I also figured this out at 18.00. That's coincidence !
> >
> > 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.
Great !
By the way, when figuring out the PortletSetFactory issue, I realized that
JetSpeed uses a lot of factories and singletons. The way in which they are
used
seems to deviate from the usual patterns described in Design Paterns book.
But I
guess it would not be worthwile to reorganize this before the next
release...
What do you think ?
> 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?
This is a good point. I've read an article in the ACM Journal written by
the
MyYahoo! techies some time ago. They reported that a large percentage of
user
never customizes the page. i.e. we can assume that storing the object tree
representation of the default PSML only once saves a significant amount of
memory. On the other hand, it must be possible to change the file even
while
the portal is running under high load.
The method that returns the portlet set should have a delay for refreshing
the
object tree to limit the number of object tree instances and the number of
times the tree has to be created. For example, assume 1 request per second
and
a maximum refresh delay of 10 seconds.
The first time, the default PSML is requested the method would read the
PSML
and store the object tree and the current value of System.currentMillis()
before
returning the object tree. The next time requests would be answered with a
page
generated from that object tree instance.
For each subsequent call, the method would check whether
(System.currentMillis() - lastAccessMillis > 10000). If this would be the
case,
it would generate a new object tree and return the new instance.
There may be more than one object tree instance at a time, but at most 6
would be
created per minute and they would be garbage collected after the last
thread that
has obtained them finishes rendering the default page. I guess at most two
referenced instances would exist in parallel, all others existing at a
given point
in time should be pending for garbage collection already.
Does that sound ok ?
> 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?
Anonymous users should not be able to customize.
The edit buttons should be 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?
Technically, this is a brilliant idea, but users may think they had
customized
the portal after the cookie-based customization and may think the
customization
has been lost when using a different machine (if they are not web
programmers
like us ;)
The alternative - registering and signing in before customization - would
avoid
that problem entirely. Users easily remain "de-facto anonymous" if they
only
provide a fantasy id and password when registring.
Many portals only exist to make users register and get data for targeted
ads to
be displayed within the portal.
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]
