yeah, that's why I thought that I would be safe when only dispatching events during the request processing to a page from the page-map.
thanks, Frank On Wed, Apr 28, 2010 at 4:48 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > most likely this concurrent access happens when you are iterating over > pages in the pagemap and invoking listeners on them and another thread > access one of the pages you are iterating over. you will have to lock > your iteration loop on the same lock wicket uses. as a rule of thumb > we do not recommend accessing pages in the pagemap yourself... > > -igor > > On Wed, Apr 28, 2010 at 6:44 AM, Frank van Lankvelt > <f.vanlankv...@onehippo.com> wrote: > > Hi all, > > > > hoping to get some debugging tips on a concurrency issue I've run into. > > What we're seeing is concurrent access to a Page instance, when our > > application is under a lot of stress. > > > > The backend is taking a lot of time, which should be handled by Wicket by > > locking on the pagemap. This is what I see in the (wicket) code and > appears > > to be working fine in ordinary circumstances. (i.e. request being > aborted > > after a minute) > > > > What's probably funny about our application is that multiple pages from > the > > same pagemap can be involved in one request cycle. After handling the > > action, but before rendering, we process events that have been delivered > to > > the session. This involves invoking listeners on different page > instances. > > (we're not serializing pages to disk) > > > > I'm happy to give more details of the way we use wicket (it's all open > > source anyway), but perhaps there are some gotcha's that I've been > missing. > > Does anyone have a clue? > > > > thanks, Frank > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
