Because those are touching the page again (some do)
Then we should move the RequestCycle.cleanup() method totally inside that block somehow.
But then we are still not there.. Because what does this do:
RequestCycle.prepare()
{
// Prepare session for request
session.init();
// Event callback
onBeginRequest();
}
What happens if request cycle. on begin request somewhere does a session thing?
Or in the resolve target phase? We now have a hack in it when making bookmarkable pages:
// FIXME Robustness: Need to take a second look on synchronizing in
// the resolve/render phase at this time, the session isn't accessed
// in a atomic, isolated manner during the request.
synchronized (session)
{
if (params.size() == 0)
{
newPage = pageFactory.newPage (pageClass);
}
else
{
newPage = pageFactory.newPage(pageClass, params);
}
}
That doesn't quite work of course because the construction of the page and the rendering of the page are seperated.
I think this we could fix by moving the construciton of the bookmarkable page to the request target instead of doing it up front.
But then we have a problem that a bookmarkable page can never set another response page in the constructor.
It has to do that now with the new Redirect Exception classes.
About that Session.update() i don't see a big problem in that. That is pure wicket code.
The bookmarkable thing and all the others callbacks (onBeginRequest) are much harder because there is where the user code is in.
On 2/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
You are right of course. The requet (target) is only synced after the
request cycle processor found out which request target it was. But, as
that target is also being used for handling the calls to target
components etc. we should not have sync problems.
The problem here is that the call to cleanup() in RequestCycle (ln
1044), which triggers the Session.update() method, is done after/
outside the synchronized code. Maybe we should change.
Eelco
On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> yes but inside the request target everything is fine.
> It is synced (the response)
> But getting the request target and the cleanup after the request target are
> just not synced.
> So in wicket we need to take that into account like i did now by making
> dirty objects a thread local.
>
> johan
>
>
>
> On 2/6/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> > sounds like something to be fixed on our end. if i am writing a request
> target and say sync on session i should not be worrying about concurrency.
> >
> > -Igor
> >
> >
> >
> >
> > On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > Huh?
> > > Why it doesn't work is pretty easy to understand...
> > > Sessions can be used just fine without a lock. Because we do take a
> session long before we sync it.
> > > And we also use it (the cleanup call) long AFTER the sync that could
> happen.
> > > So when 2 request are comming in. there can be a sync lock somewhere.
> > > But the sync lock is not doing the whole session handling only a small
> part.
> > >
> > > Just look at the RequestCycle.steps() method.
> > > If we really want to sync save everything then that method should be
> totally synced but that is not what we want.
> > >
> > > johan
> > >
> > >
> > >
> > > On 2/6/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> > >
> > > > I'm not sure whether that is the best solution. I think we should
> > > > first find out why our session synchronization isn't working in this
> > > > case.
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 2/5/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> > > > > Is there more then one request happening at the same time?
> > > > > Can you check that with a system.out somewhere or a breakpoint?
> > > > >
> > > > > It looks like 2 or more request at the same time modifying the dirty
> objects
> > > > > List (pages and pagemaps)
> > > > >
> > > > > We could fix this by making the List a threadlocal or syncing on it
> > > > > everywhere the list is being iterated or altered.
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 2/5/06, Mark Derricutt < [EMAIL PROTECTED]> wrote:
> > > > > > Hey all, I'm noticing a few
> > > > > ConcurrentModificationExceptions in my logs during
> an AJAX
> > > > > update (SelfUpdating behaviour) under wicket
> 1.2cvs-from-this-morning:
> > > > > >
> > > > > > 16:55:56.499 WARN!! Exception for
> > > > >
> /app?path=1:feedback&interface=IBehaviorListener&behaviorId=0&random=
> > > > > 0.9183153983106074
> > > > > > java.util.ConcurrentModificationException
> > > > > > at
> > > > >
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:374)
> > > > > > at java.util.AbstractList$Itr.next (AbstractList.java:345)
> > > > > > at wicket.Session.update(Session.java:742)
> > > > > > at
> > > > >
> wicket.protocol.http.WebSession.update(WebSession.java:115)
> > > > > > at wicket.RequestCycle.cleanUp (RequestCycle.java:787)
> > > > > > at wicket.RequestCycle.steps (RequestCycle.java:1059)
> > > > > > at wicket.RequestCycle.request(RequestCycle.java :524)
> > > > > > at
> > > > > wicket.protocol.http.WicketServlet.doGet
> (WicketServlet.java:205)
> > > > > > at javax.servlet.http.HttpServlet.service
> > > > > (HttpServlet.java:740)
> > > > > > at
> > > > >
> javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > > > > > at
> > > > >
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
> > > > > > at
> > > > >
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch
> > > > > (WebApplicationHandler.java:294)
> > > > > > at
> > > > >
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
> > > > > > at
> > > > >
> org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
> > > > > > at
> > > > >
> org.mortbay.jetty.servlet.WebApplicationContext.handle
> > > > > (WebApplicationContext.java:525)
> > > > > > at
> > > > >
> org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
> > > > > > at
> > > > >
> org.mortbay.http.HttpServer.service(HttpServer.java:879)
> > > > > > at
> org.mortbay.http.HttpConnection.service
> > > > > (HttpConnection.java :790)
> > > > > > at
> > > > >
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:961)
> > > > > > at
> > > > >
> org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
> > > > > > at
> > > > > org.mortbay.http.SocketListener.handleConnection
> > > > > ( SocketListener.java:218)
> > > > > > at
> > > > > org.mortbay.util.ThreadedServer.handle
> (ThreadedServer.java:300)
> > > > > > at
> > > > >
> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)
> > > > > >
> > > > > >
> > > > > > Known issue?
> > > > > >
> > > > > > --
> > > > > > i like my video games - mamma said they are gonna melt my brains
> > > > > > i like my video games - i don't care what daddy said; they're my
> reality
> > > > > > - henning pauly
> > > > >
> > > > >
> > > >
> > > >
> > > >
> -------------------------------------------------------
> > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > > > for problems? Stop! Download the new AJAX search engine that makes
> > > > searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK!
> > > >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> > > > _______________________________________________
> > > > Wicket-user mailing list
> > > > Wicket-user@lists.sourceforge.net
> > > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > >
> > >
> > >
> >
> >
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
