You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Johan Compagner <jc...@gmail.com> on 2007/04/18 16:53:21 UTC
the new cleaning up of FeedbackMessages
RequestCycle.detach does this;
getSession().cleanupFeedbackMessages();
that results in this:
// If session scoped, rendered messages got indeed cleaned up, mark
the
// session as dirty
if (feedbackMessages.clear(RENDERED_SESSION_SCOPED_MESSAGES) > 0)
{
dirty();
}
feedbackMessages.clear(MESSAGES_FOR_COMPONENTS);
and then the last part. clear all feedbackmessages which have components...
this does mean that IF the session is used in another page from another
pagemap
we are clearing also the feedbackMessagges of that request.
i know it is not very likely that we will see that happening but it is
possible
that 2 threads are interacting with the same feedbackMessages now.
johan
Re: the new cleaning up of FeedbackMessages
Posted by Igor Vaynberg <ig...@gmail.com>.
https://issues.apache.org/jira/browse/WICKET-484
-igor
On 4/18/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > cases will be rare but possible. it would require two threads in two
> > different pagemaps processing simultaneously.
> >
> > so user goes to a form page, opens it in a new tab, submits in first,
> and
> > then submits in the other. now one tab can have its feedback messages
> > missing.
> >
> > or maybe a user working in multiple tabs and having two different pages
> with
> > forms on them. or maybe not even forms, just some status feedback
> messages
> > can also be missing.
> >
> > should we fix this? i think so.
>
> ok, fair enough. If someone wants to open a JIRA issue we can take
> that to look into this further.
>
> Eelco
>
Re: the new cleaning up of FeedbackMessages
Posted by Eelco Hillenius <ee...@gmail.com>.
> cases will be rare but possible. it would require two threads in two
> different pagemaps processing simultaneously.
>
> so user goes to a form page, opens it in a new tab, submits in first, and
> then submits in the other. now one tab can have its feedback messages
> missing.
>
> or maybe a user working in multiple tabs and having two different pages with
> forms on them. or maybe not even forms, just some status feedback messages
> can also be missing.
>
> should we fix this? i think so.
ok, fair enough. If someone wants to open a JIRA issue we can take
that to look into this further.
Eelco
Re: the new cleaning up of FeedbackMessages
Posted by Igor Vaynberg <ig...@gmail.com>.
cases will be rare but possible. it would require two threads in two
different pagemaps processing simultaneously.
so user goes to a form page, opens it in a new tab, submits in first, and
then submits in the other. now one tab can have its feedback messages
missing.
or maybe a user working in multiple tabs and having two different pages with
forms on them. or maybe not even forms, just some status feedback messages
can also be missing.
should we fix this? i think so.
-igor
On 4/18/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > this does mean that IF the session is used in another page from another
> > pagemap
> > we are clearing also the feedbackMessagges of that request.
>
> Yep. See my commit comments about 'agressive' cleanup. There can be
> disagreement for specific situations whether this is the best
> implementation, which is why it is put in an overridable method. But I
> rather cleanup agresively so that we avoid having memory leaks.
>
> > i know it is not very likely that we will see that happening but it is
> > possible
> > that 2 threads are interacting with the same feedbackMessages now.
>
> Do you have a case? If there is a potential concurrency problem, we
> should fix it. And maybe the conclusion would be that a non-agressive
> cleanup is better. But for the moment, I prefer to stay on the safe
> side.
>
> Eelco
>
Re: the new cleaning up of FeedbackMessages
Posted by Eelco Hillenius <ee...@gmail.com>.
> this does mean that IF the session is used in another page from another
> pagemap
> we are clearing also the feedbackMessagges of that request.
Yep. See my commit comments about 'agressive' cleanup. There can be
disagreement for specific situations whether this is the best
implementation, which is why it is put in an overridable method. But I
rather cleanup agresively so that we avoid having memory leaks.
> i know it is not very likely that we will see that happening but it is
> possible
> that 2 threads are interacting with the same feedbackMessages now.
Do you have a case? If there is a potential concurrency problem, we
should fix it. And maybe the conclusion would be that a non-agressive
cleanup is better. But for the moment, I prefer to stay on the safe
side.
Eelco