I didn't propose that completely i think about doing this Thread t = (Thread)usedSession.get(this); // See now 'this' instead of the page idwhile (t != null && t !=
Thread.currentThread()){try
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
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 <
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
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
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=detail&aid=1554508&group_id=119783&atid=684975
and assigned it to Johan to look at if he has some spare time.
Eelco
On 9/7/06, Iman Rahmatizadeh <[EMAIL PROTEC
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 adds
> 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
> oth
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 w
> 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
Ob
> 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
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. Any
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
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 catch
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
15 matches
Mail list logo
