Thx,Currently we release the pages only at the end of the request anyway. So what we can dois just remove everything out of the used map for the current thread always after the requestand call notify all..
Then it should always be cleanup.johanOn 9/8/06, Eelco Hillenius [EMAIL PROTECTED]
wrote:I
But if you have two threads working on that page, the first thread to
end would also remove the page reference for the second?
Eelco
On 9/8/06, Johan Compagner [EMAIL PROTECTED] wrote:
Thx,
Currently we release the pages only at the end of the request anyway. So
what we can do
is just
you cant have two threads working on a page - thats the whole point of syncing :)-IgorOn 9/8/06, Eelco Hillenius
[EMAIL PROTECTED] wrote:But if you have two threads working on that page, the first thread to
end would also remove the page reference for the second?EelcoOn 9/8/06, Johan Compagner
Yes smartass, of course. That's why the wait (on session) is there.
However, if you look at this:
Thread t = (Thread)usedPages.get(id);
while (t != null t != Thread.currentThread())
{
try
There's a problem with my app, where clicking on a link would generate
an ArrayOutOfBoundsException. However, pressing the back button and
clicking on any other link in the page would cause an infinite loop in
the getPage method of Session, between lines 405 and 415 (Wicket
1.2.2),where the
Can you reproduce this in a sample and make a bug report out of it?The used pages should be cleared in a finaly block in the page detach.IF that doesn't happen somehow then that is a bug.johan
On 9/7/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
There's a problem with my app, where clicking on a
I've tried to reproduce it, but without luck so far.
Looking at that code, I was wondering about a few things though...
what is the idea on the whole thread thing (usedPages)? Why would t !=
Thread.currentThread() be recoverable? Why not use a thread local
instead?
Why throw an exception on
A thread local can't be used ofcourse because it is map that has to be shared across threads!Did you look at the code that releases the usedPages?Page.internalDetach() calls getSession().pageDetached(this);
which does:usedPages.remove(page.getId()); notifyAll();and all synched on session. So
On 9/7/06, Johan Compagner [EMAIL PROTECTED] wrote:
A thread local can't be used ofcourse because it is map that has to be
shared across threads!
Yes, of course I got that. But while (t != null t !=
Thread.currentThread()) looked to me like you are trying to achieve
something similar. Anyway,
The InterruptedException can be ignored completely i guess. But it is such an rare case that that would
happen.Is it? If you give up the lock by calling wait, and another threadaccesses it in the mean time (1 sec window), it will happen.no that exception is thrown when you take another thread
no that exception is thrown when you take another thread instance and call
interrupt() on that
when that thread is in wait.
Well, if another request comes in for the same session, that is
exactly what happens, right?
Maybe I don't understand it properly, but this is from the javadocs of
Well, if another request comes in for the same session, that isexactly what happens, right?
Maybe I don't understand it properly, but this is from the javadocs ofObject.wait' The current thread must own this object's monitor.This method causes the current thread (call it T) to place itself in
the
Its exactly that. You have to have a lock on the monitor to call wait.
When you start waiting you don't lock in anymore so others can take the lock
and also see that they also have to wait and start waiting.
Then the first thread that calls notifyAll() on the monitor lock (where the
other 2
Well here's a trace of what happens that causes the problem :
During the RESOLVE_TARGET step of RequestCycle, the target is trying to
be resolved using the DefaultRequestTargetResolverStrategy, which first
inside the resolveRenderedPage() method uses Session.getPage() to get
the page,(which
I get how that happens now. Thanks for tracing and explaining. Nasty
one. I opened up a bug
http://sourceforge.net/tracker/index.php?func=detailaid=1554508group_id=119783atid=684975
and assigned it to Johan to look at if he has some spare time.
Eelco
On 9/7/06, Iman Rahmatizadeh [EMAIL
15 matches
Mail list logo
