Re: CouldNotLockPageException using localized RequestMapper URLs
Thanks - I did that, and found the culprit was a file upload (that part was
okay) which fed into an piece of image resizing code:
Graphics2D graphics2D = rescaledImage.createGraphics();
which the stack trace showed was waiting forever on some other AWT init
thread.
So I just kicked it to the curb and used another image scaling library from
http://code.google.com/p/java-image-scaling/ and the problem has gone
away! So not wicket related at all.
In retrospect, I can't think of a more informative way the framework could
have helped me discover this - my breakthru came from the old
tried-and-true method of finding a way to reproduce the issue (of course
that is the hard part - seems like it took forever, trying to explore all
the functions in my system) and then when it finally happened, doing a
thread dump.
Anyway, situation resolved! Back to happy wicket coding...
-- Jim
On Wed, Oct 5, 2011 at 4:27 AM, Martin Grigorov mgrigo...@apache.orgwrote:
Hi,
Page ids are session relative. I.e. different users may have the same
page id. The actual key is (sessionId, pageId).
Better dump the stacktraces and see why the thread that acquired the
lock needs more than a minute for it to do its job.
On Tue, Oct 4, 2011 at 8:37 PM, Jim Pinkham pinkh...@gmail.com wrote:
Maybe I'm doing something out of the ordinary - I have several
independant
'clients' using their own versions of my site, and it's been working OK
till
recent increase in my site's use by several clients at once using the
'same'
pages.
I have a ClientFirstRootRequestMapper extends AbstractComponentMapper
that
pulls the client prefix from my URL and then chains the call to
super.mapRequest() with the prefix removed from the url - this has been
working fine since early 1.5.
But now I have these lockups in production recently. My theory is that
they
are somehow sharing ids in the page map(s) such that locking behavior is
not
correct. I'm working on a quickstart, but I thought I'd first throw out
some details and see if anyone has a better theory? Obviously, this is
a
pretty major issue for me, since it brings my whole site down, with a
bunch
of http-80-xx threads showing entries like this:
WARN - PageAccessSynchronizer - http-80-65 failed to acquire lock to
page 7, attempted for 1 minute out of allowed 1 minute
ERROR - PageAccessSynchronizer - failed to acquire lockheld by
http-80-70. Would have thrown:
org.apache.wicket.page.CouldNotLockPageException: Could not lock page 7.
Attempt lasted 1 minute
at
org.apache.wicket.page.PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:155)
at
org.apache.wicket.page.PageAccessSynchronizer$2.touchPage(PageAccessSynchronizer.java:214)
...
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Oct 3, 2011 5:57:55 PM org.apache.tomcat.util.net.JIoEndpoint
createWorkerThread
INFO: Maximum number of threads (200) created for connector with address
null and port 80
INFO - AuctionApplication - Bye
I already tried this attempted fix to bypass throwing this exception and
just let it get the lock anyway (I'm desparate here).
String info= held by: ;
IteratorPageLock locks =
this.locks.get().values().iterator();
while (locks.hasNext()) {
PageLock culprit = locks.next();
info += culprit.getThread().getName() + , ;
}
if (info.endsWith(, ))
info = info.substring(0, info.length()-2);
logger.error(failed to acquire lock+info+. Would have
thrown:
,
/*throw*/ new CouldNotLockPageException(pageId,
thread.getName(), timeout));
In my app, I have mounted a CatalogPage like this:
getRootRequestMapperAsCompound().add(new MountedMapper(/catalog,
CatalogPage.class, e));
Running this locally with debug turned on for PageAccessSynchronizer, I
open
two windows and load this page with different prefixes - it appears they
use
the same page id 0 (which might be OK but I'm suspicious..?)
loading http://localhost:8080/clientOne/catalog
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer -
'qtp10217370-20'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer -
qtp10217370-20
acquired lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer -
'qtp10217370-15'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer -
qtp10217370-15
acquired lock to page 0
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer -
Re: CouldNotLockPageException using localized RequestMapper URLs
Hi,
Page ids are session relative. I.e. different users may have the same
page id. The actual key is (sessionId, pageId).
Better dump the stacktraces and see why the thread that acquired the
lock needs more than a minute for it to do its job.
On Tue, Oct 4, 2011 at 8:37 PM, Jim Pinkham pinkh...@gmail.com wrote:
Maybe I'm doing something out of the ordinary - I have several independant
'clients' using their own versions of my site, and it's been working OK till
recent increase in my site's use by several clients at once using the 'same'
pages.
I have a ClientFirstRootRequestMapper extends AbstractComponentMapper that
pulls the client prefix from my URL and then chains the call to
super.mapRequest() with the prefix removed from the url - this has been
working fine since early 1.5.
But now I have these lockups in production recently. My theory is that they
are somehow sharing ids in the page map(s) such that locking behavior is not
correct. I'm working on a quickstart, but I thought I'd first throw out
some details and see if anyone has a better theory? Obviously, this is a
pretty major issue for me, since it brings my whole site down, with a bunch
of http-80-xx threads showing entries like this:
WARN - PageAccessSynchronizer - http-80-65 failed to acquire lock to
page 7, attempted for 1 minute out of allowed 1 minute
ERROR - PageAccessSynchronizer - failed to acquire lockheld by
http-80-70. Would have thrown:
org.apache.wicket.page.CouldNotLockPageException: Could not lock page 7.
Attempt lasted 1 minute
at
org.apache.wicket.page.PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:155)
at
org.apache.wicket.page.PageAccessSynchronizer$2.touchPage(PageAccessSynchronizer.java:214)
...
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Oct 3, 2011 5:57:55 PM org.apache.tomcat.util.net.JIoEndpoint
createWorkerThread
INFO: Maximum number of threads (200) created for connector with address
null and port 80
INFO - AuctionApplication - Bye
I already tried this attempted fix to bypass throwing this exception and
just let it get the lock anyway (I'm desparate here).
String info= held by: ;
IteratorPageLock locks = this.locks.get().values().iterator();
while (locks.hasNext()) {
PageLock culprit = locks.next();
info += culprit.getThread().getName() + , ;
}
if (info.endsWith(, ))
info = info.substring(0, info.length()-2);
logger.error(failed to acquire lock+info+. Would have thrown:
,
/*throw*/ new CouldNotLockPageException(pageId,
thread.getName(), timeout));
In my app, I have mounted a CatalogPage like this:
getRootRequestMapperAsCompound().add(new MountedMapper(/catalog,
CatalogPage.class, e));
Running this locally with debug turned on for PageAccessSynchronizer, I open
two windows and load this page with different prefixes - it appears they use
the same page id 0 (which might be OK but I'm suspicious..?)
loading http://localhost:8080/clientOne/catalog
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - 'qtp10217370-20'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - qtp10217370-20
acquired lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - 'qtp10217370-15'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - qtp10217370-15
acquired lock to page 0
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - 'qtp10217370-18'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - qtp10217370-18
acquired lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - qtp10217370-15
released lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - qtp10217370-15
notifying blocked threads
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - qtp10217370-20
released lock to page 0
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - qtp10217370-20
notifying blocked threads
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - qtp10217370-18
released lock to page 0
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - qtp10217370-18
notifying blocked threads
then http://localhost:8080/clientTwo/catalog
40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer - 'qtp10217370-19'
attempting to acquire lock to page with id '0'
40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer - qtp10217370-19
acquired lock to page 0
40953 [qtp10217370-19] DEBUG -
CouldNotLockPageException using localized RequestMapper URLs
Maybe I'm doing something out of the ordinary - I have several independant
'clients' using their own versions of my site, and it's been working OK till
recent increase in my site's use by several clients at once using the 'same'
pages.
I have a ClientFirstRootRequestMapper extends AbstractComponentMapper that
pulls the client prefix from my URL and then chains the call to
super.mapRequest() with the prefix removed from the url - this has been
working fine since early 1.5.
But now I have these lockups in production recently. My theory is that they
are somehow sharing ids in the page map(s) such that locking behavior is not
correct. I'm working on a quickstart, but I thought I'd first throw out
some details and see if anyone has a better theory? Obviously, this is a
pretty major issue for me, since it brings my whole site down, with a bunch
of http-80-xx threads showing entries like this:
WARN - PageAccessSynchronizer - http-80-65 failed to acquire lock to
page 7, attempted for 1 minute out of allowed 1 minute
ERROR - PageAccessSynchronizer - failed to acquire lockheld by
http-80-70. Would have thrown:
org.apache.wicket.page.CouldNotLockPageException: Could not lock page 7.
Attempt lasted 1 minute
at
org.apache.wicket.page.PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:155)
at
org.apache.wicket.page.PageAccessSynchronizer$2.touchPage(PageAccessSynchronizer.java:214)
...
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Oct 3, 2011 5:57:55 PM org.apache.tomcat.util.net.JIoEndpoint
createWorkerThread
INFO: Maximum number of threads (200) created for connector with address
null and port 80
INFO - AuctionApplication - Bye
I already tried this attempted fix to bypass throwing this exception and
just let it get the lock anyway (I'm desparate here).
String info= held by: ;
IteratorPageLock locks = this.locks.get().values().iterator();
while (locks.hasNext()) {
PageLock culprit = locks.next();
info += culprit.getThread().getName() + , ;
}
if (info.endsWith(, ))
info = info.substring(0, info.length()-2);
logger.error(failed to acquire lock+info+. Would have thrown:
,
/*throw*/ new CouldNotLockPageException(pageId,
thread.getName(), timeout));
In my app, I have mounted a CatalogPage like this:
getRootRequestMapperAsCompound().add(new MountedMapper(/catalog,
CatalogPage.class, e));
Running this locally with debug turned on for PageAccessSynchronizer, I open
two windows and load this page with different prefixes - it appears they use
the same page id 0 (which might be OK but I'm suspicious..?)
loading http://localhost:8080/clientOne/catalog
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - 'qtp10217370-20'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - qtp10217370-20
acquired lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - 'qtp10217370-15'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - qtp10217370-15
acquired lock to page 0
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - 'qtp10217370-18'
attempting to acquire lock to page with id '0'
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - qtp10217370-18
acquired lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - qtp10217370-15
released lock to page 0
13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer - qtp10217370-15
notifying blocked threads
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - qtp10217370-20
released lock to page 0
13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer - qtp10217370-20
notifying blocked threads
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - qtp10217370-18
released lock to page 0
13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer - qtp10217370-18
notifying blocked threads
then http://localhost:8080/clientTwo/catalog
40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer - 'qtp10217370-19'
attempting to acquire lock to page with id '0'
40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer - qtp10217370-19
acquired lock to page 0
40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer - 'qtp10217370-19'
attempting to acquire lock to page with id '0'
40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer - qtp10217370-19
acquired lock to page 0
40969 [qtp10217370-19] DEBUG - PageAccessSynchronizer - 'qtp10217370-19'
attempting to acquire lock to page with id '0'
40969 [qtp10217370-19] DEBUG - PageAccessSynchronizer - qtp10217370-19
