how could it be set up incorrectly? we got the message part of the NPE
just not the stack trace.
Eelco Hillenius wrote:
>
>> could it be this code that's not logging the whole exception?
>>
>> protected void logRuntimeException(RuntimeException e)
>> {
>> log.
no repro case currently.
Johan Compagner wrote:
>
> can't you debug it and break on the exception NullPointer?
>
> But i agree somehow we should log this better.
>
> On 6/18/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> aha. we might have two of these bugs, but i'm getting this
can't you debug it and break on the exception NullPointer?
But i agree somehow we should log this better.
On 6/18/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
aha. we might have two of these bugs, but i'm getting this trace
now. does
anyone have any idea what line of code it is that is fa
> could it be this code that's not logging the whole exception?
>
> protected void logRuntimeException(RuntimeException e)
> {
> log.error(e.getMessage(), e);
> }
That should typically print the stack trace if your logging
configuration is set up properly.
could it be this code that's not logging the whole exception?
protected void logRuntimeException(RuntimeException e)
{
log.error(e.getMessage(), e);
}
Jonathan Locke wrote:
>
>
> aha. we might have two of these bugs, but i'm getting this trace now.
>
aha. we might have two of these bugs, but i'm getting this trace now. does
anyone have any idea what line of code it is that is failing to print the
stack trace for this NPE into the log? it looks like an NPE is causing the
processing step to restart over and over again. would be a good fix t
this is not it. the server with the problem is not even running a proxy.
any other ideas anyone?
Al Maw wrote:
>
> I've seen this happen if you run behind a mod_proxy and fail to set up
> the ProxyPassReverse setting properly. Make sure you have
> ProxyPassReverseCookiePath, too. See the wik
I've seen this happen if you run behind a mod_proxy and fail to set up
the ProxyPassReverse setting properly. Make sure you have
ProxyPassReverseCookiePath, too. See the wiki for details.
Al
Jonathan Locke wrote:
>
> anyone have any ideas on what might cause this? in particular can a user
> exc
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
23 matches
Mail list logo
