Stephan Hesmer wrote:
> Hi,
>
> A while ago, there was a discussion about concurrent users and how fast they
> are processed. I spent some time to find and eleminate the occuring
> problems. A short summary:
>
Thanks for your effort!
> * There are a lot of unnecessery synchronized statements in the generated
> PortletSet tree and related java files such as PortletConfig and others.
> They are not needed and we can remove them safely.
>
> * We store per-user information in PortletConfig. That is not correct
> because PortletConfig only exists once per Portlet. Also, it leads to
> failures when more users get their home page concurrently (The portlets are
> mixed randomly - this means that they switch position at will).
> I looked in detail at this issue and know now exactly what is going on
> there. If one is interested I can post a summary with diagrams of it.
> -> I created a new class (PortletUserConfig) to save per-user information.
> The PortletUserConfig is only stored in the PortletSet tree, that is created
> in every request.
>
I agree in whole. This work is needed. We have been delaying this effort, due to the
new
PortletAPI, but I think the changes go in the right direction.
I tested having PortletSets cached in the session. This brought the problem that
portlets
were not being correctly expired during the session, as expiration happens in
getPortlet()
during creation of the PortletSet.
I suggest taking out setPortletConfig() from the Portlet API and changing to
init(config),
so that there is no reasonable way to spoil the config again.
We could do the following:
- Maybe you could want to have commit rights, or will the changes be commited by Ingo?
- You post the changes' description for discussion, but I think the best communication
would be in the following points...
- take 24-48 hours for people to commit other "minor" changes in the main branch
(I will commit the JAXP/TRAX changes, don't think they interfere)
- open a branch for this work.
- apply your patches in this branch
- test a little bit
- have a IRC meeting to discuss about any pending problems or unforessen implications
(maybe we understand things in different ways, and this can lead to divergent work).
Also, if the main developers understand the changes,and the reasons, it is less
likely that incompatible changes that spoil the model appear later.
- test more :) (don't forget the jsp classes, that don't get compiled during ./build)
- merge the patches into the main branch
The reasons is that I have also some changes in related classes, and while I don't
think I have problems,
maybe I have seen things that you forgot, or the other way round. I prefer having a
branch, so that we
can take time to think if something breaks (conflicts) without being pressed by Sam
Ruby's GUMP :)
> BTW: Raphael, did you modify these classes for the new layout system? I
> modified the following classes:
> * PortletSet
> * a few factory classes
> * a few controller classes
> * a few control classes
> * a few config classes
> * a few other classes
>
Don't know Raphael. I have minor pending changes (some related to these problems) in a
lot of these classes.
There will be conflicts, but I don't think anything serious. They should be compatible
for the major part.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
