Re: Problems after Upgrade from older Version with Ajax
I found the bug! Thanks to everyone who gave me input on where I could look for the error. The cause was that I have my own session implementation which overrides detach(). Unfortunately, I forgot to call super.detach() there, so the page lock was never released. In the old Wicket version the workflow must have been different, so the issue didn’t show up before. Am Do., 20. Nov. 2025 um 15:02 Uhr schrieb Malte < [email protected]>: > unlockPage is only called after the one-minute period has passed. > > I haven't changed anything in the Wicket source code. However, I did > override the WebApplication and return a derived version in newSession > where I carry a few additional values. > > At which point should the page lock actually be released? I’d step through > it with the debugger to find the cause. > > Am Do., 20. Nov. 2025 um 13:28 Uhr schrieb Bas Gooren >: > >> Hi Malte, >> >> Hmmm... I have never seen this happening in all the time I have used >> wicket >> (since the early beta’s!). >> >> From your stack traces it looks like you are using standard java >> serialization. >> I also only see the thread waiting for the page to unlock, no other >> threads >> are working on pages. >> >> I see you have enabled debug logging for DefaultPageLockManager; It should >> also be releasing locks (‘[thread]’ released lock to page [id]). >> >> I recommend setting some breakpoints to see whether >> (a) DPLM#unlockAllPages() and DPLM#unlockPage() are called or not, >> (b) *if* they are called, if the pageLockIterator is empty (so basically, >> inspect this.locks). >> >> Should the methods not be called, there is a problem higher up the call >> stack. But they should be called, according to the wicket sources. >> >> Do you have a vanilla wicket app or are you using any custom code for >> session mgt? >> >> Met vriendelijke groet, >> Kind regards, >> >> Bas Gooren >> >> >> Op 20 nov 2025, 13:13:50 schreef Malte > .invalid >> >: >> >> > I’ve solved the serialization issue—at least I haven’t seen any errors. >> > However, the page-lock problem still persists. >> > Here is an excerpt from the page log: >> > 2025-11-20 13:03:49,953 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-55' >> > attempting to acquire lock to page with id '0' >> > 2025-11-20 13:03:49,953 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-55 >> acquired >> > lock to page 0 >> > 2025-11-20 13:03:50,858 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-55' >> > attempting to acquire lock to page with id '0' >> > 2025-11-20 13:03:50,859 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-55 >> acquired >> > lock to page 0 >> > 2025-11-20 13:03:57,664 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' >> > attempting to acquire lock to page with id '0' >> > 2025-11-20 13:03:57,664 DEBUG >> > org.apache.wicket.page.PageAccessSynchronizer:252 - qtp32070961-55 >> waiting >> > for lock to page 0 for PT1M >> > 2025-11-20 13:04:57,666 WARN >> > org.apache.wicket.page.DefaultPageLockManager:140 - Thread >> 'qtp32070961-56' >> > failed to acquire lock to page with id '0', attempted for PT1M0.0025716S >> > out of allowed PT1M. The thread that holds the lock has name >> > 'qtp32070961-55'. >> > 2025-11-20 13:04:57,669 WARN >> > org.apache.wicket.page.DefaultPageLockManager:114 - "qtp32070961-55" >> prio=5 >> > tid=55 state=TIMED_WAITING >> > org.apache.wicket.util.lang.Threads$ThreadDump >> > at [email protected]/jdk.internal.misc.Unsafe.park(Native Method) >> > at [email protected] >> > /java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252) >> > at [email protected] >> > >> /java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1679) >> > at >> > >> app//org.eclipse.jetty.util.thread.AutoLock$WithCondition.awaitNanos(AutoLock.java:194) >> > at >> > >> app//org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:273) >> > at >> > >> app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1169) >> > at >> > >> app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1186) >> > at [email protected]/java.lang.Thread.run(Thread.java:840) >> > 2025-11-20 13:04:57,687 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' >> > attempting to acquire lock to page with id '1' >> > 2025-11-20 13:04:57,687 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 >> acquired >> > lock to page 1 >> > 2025-11-20 13:04:57,713 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' >> > attempting to acquire lock to page with id '1' >> > 2025-11-20 13:04:57,713 DEBUG >> > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 >> acquired >> > lock to page 1 >> > 2025-11-20 13:04:57,727 DEBUG >> >
Re: Problems after Upgrade from older Version with Ajax
unlockPage is only called after the one-minute period has passed. I haven't changed anything in the Wicket source code. However, I did override the WebApplication and return a derived version in newSession where I carry a few additional values. At which point should the page lock actually be released? I’d step through it with the debugger to find the cause. Am Do., 20. Nov. 2025 um 13:28 Uhr schrieb Bas Gooren : > Hi Malte, > > Hmmm... I have never seen this happening in all the time I have used wicket > (since the early beta’s!). > > From your stack traces it looks like you are using standard java > serialization. > I also only see the thread waiting for the page to unlock, no other threads > are working on pages. > > I see you have enabled debug logging for DefaultPageLockManager; It should > also be releasing locks (‘[thread]’ released lock to page [id]). > > I recommend setting some breakpoints to see whether > (a) DPLM#unlockAllPages() and DPLM#unlockPage() are called or not, > (b) *if* they are called, if the pageLockIterator is empty (so basically, > inspect this.locks). > > Should the methods not be called, there is a problem higher up the call > stack. But they should be called, according to the wicket sources. > > Do you have a vanilla wicket app or are you using any custom code for > session mgt? > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > > Op 20 nov 2025, 13:13:50 schreef Malte .invalid > >: > > > I’ve solved the serialization issue—at least I haven’t seen any errors. > > However, the page-lock problem still persists. > > Here is an excerpt from the page log: > > 2025-11-20 13:03:49,953 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-55' > > attempting to acquire lock to page with id '0' > > 2025-11-20 13:03:49,953 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-55 > acquired > > lock to page 0 > > 2025-11-20 13:03:50,858 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-55' > > attempting to acquire lock to page with id '0' > > 2025-11-20 13:03:50,859 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-55 > acquired > > lock to page 0 > > 2025-11-20 13:03:57,664 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > > attempting to acquire lock to page with id '0' > > 2025-11-20 13:03:57,664 DEBUG > > org.apache.wicket.page.PageAccessSynchronizer:252 - qtp32070961-55 > waiting > > for lock to page 0 for PT1M > > 2025-11-20 13:04:57,666 WARN > > org.apache.wicket.page.DefaultPageLockManager:140 - Thread > 'qtp32070961-56' > > failed to acquire lock to page with id '0', attempted for PT1M0.0025716S > > out of allowed PT1M. The thread that holds the lock has name > > 'qtp32070961-55'. > > 2025-11-20 13:04:57,669 WARN > > org.apache.wicket.page.DefaultPageLockManager:114 - "qtp32070961-55" > prio=5 > > tid=55 state=TIMED_WAITING > > org.apache.wicket.util.lang.Threads$ThreadDump > > at [email protected]/jdk.internal.misc.Unsafe.park(Native Method) > > at [email protected] > > /java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252) > > at [email protected] > > > /java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1679) > > at > > > app//org.eclipse.jetty.util.thread.AutoLock$WithCondition.awaitNanos(AutoLock.java:194) > > at > > > app//org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:273) > > at > > > app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1169) > > at > > > app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1186) > > at [email protected]/java.lang.Thread.run(Thread.java:840) > > 2025-11-20 13:04:57,687 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > > attempting to acquire lock to page with id '1' > > 2025-11-20 13:04:57,687 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 > acquired > > lock to page 1 > > 2025-11-20 13:04:57,713 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > > attempting to acquire lock to page with id '1' > > 2025-11-20 13:04:57,713 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 > acquired > > lock to page 1 > > 2025-11-20 13:04:57,727 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > > attempting to acquire lock to page with id '1' > > 2025-11-20 13:04:57,727 DEBUG > > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 > acquired > > lock to page 1 > > > > It looks to me as if the page lock is not being released. > > I’ve attached the complete Wicket log file again. > > > > Am Do., 20. Nov. 2025 um 11:17 Uhr schrieb Bas Gooren > > >: > > > >> Hi Malte, > >> > >> I don’t see anything off in your thread dump. > >> > >> Thread qtp23808661-65 is not doing anything. > >> None
Re: Problems after Upgrade from older Version with Ajax
Hi Malte, Hmmm... I have never seen this happening in all the time I have used wicket (since the early beta’s!). >From your stack traces it looks like you are using standard java serialization. I also only see the thread waiting for the page to unlock, no other threads are working on pages. I see you have enabled debug logging for DefaultPageLockManager; It should also be releasing locks (‘[thread]’ released lock to page [id]). I recommend setting some breakpoints to see whether (a) DPLM#unlockAllPages() and DPLM#unlockPage() are called or not, (b) *if* they are called, if the pageLockIterator is empty (so basically, inspect this.locks). Should the methods not be called, there is a problem higher up the call stack. But they should be called, according to the wicket sources. Do you have a vanilla wicket app or are you using any custom code for session mgt? Met vriendelijke groet, Kind regards, Bas Gooren Op 20 nov 2025, 13:13:50 schreef Malte : > I’ve solved the serialization issue—at least I haven’t seen any errors. > However, the page-lock problem still persists. > Here is an excerpt from the page log: > 2025-11-20 13:03:49,953 DEBUG > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-55' > attempting to acquire lock to page with id '0' > 2025-11-20 13:03:49,953 DEBUG > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-55 acquired > lock to page 0 > 2025-11-20 13:03:50,858 DEBUG > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-55' > attempting to acquire lock to page with id '0' > 2025-11-20 13:03:50,859 DEBUG > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-55 acquired > lock to page 0 > 2025-11-20 13:03:57,664 DEBUG > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > attempting to acquire lock to page with id '0' > 2025-11-20 13:03:57,664 DEBUG > org.apache.wicket.page.PageAccessSynchronizer:252 - qtp32070961-55 waiting > for lock to page 0 for PT1M > 2025-11-20 13:04:57,666 WARN > org.apache.wicket.page.DefaultPageLockManager:140 - Thread 'qtp32070961-56' > failed to acquire lock to page with id '0', attempted for PT1M0.0025716S > out of allowed PT1M. The thread that holds the lock has name > 'qtp32070961-55'. > 2025-11-20 13:04:57,669 WARN > org.apache.wicket.page.DefaultPageLockManager:114 - "qtp32070961-55" prio=5 > tid=55 state=TIMED_WAITING > org.apache.wicket.util.lang.Threads$ThreadDump > at [email protected]/jdk.internal.misc.Unsafe.park(Native Method) > at [email protected] > /java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252) > at [email protected] > /java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1679) > at > app//org.eclipse.jetty.util.thread.AutoLock$WithCondition.awaitNanos(AutoLock.java:194) > at > app//org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:273) > at > app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1169) > at > app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1186) > at [email protected]/java.lang.Thread.run(Thread.java:840) > 2025-11-20 13:04:57,687 DEBUG > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > attempting to acquire lock to page with id '1' > 2025-11-20 13:04:57,687 DEBUG > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 acquired > lock to page 1 > 2025-11-20 13:04:57,713 DEBUG > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > attempting to acquire lock to page with id '1' > 2025-11-20 13:04:57,713 DEBUG > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 acquired > lock to page 1 > 2025-11-20 13:04:57,727 DEBUG > org.apache.wicket.page.DefaultPageLockManager:105 - 'qtp32070961-56' > attempting to acquire lock to page with id '1' > 2025-11-20 13:04:57,727 DEBUG > org.apache.wicket.page.DefaultPageLockManager:131 - qtp32070961-56 acquired > lock to page 1 > > It looks to me as if the page lock is not being released. > I’ve attached the complete Wicket log file again. > > Am Do., 20. Nov. 2025 um 11:17 Uhr schrieb Bas Gooren >: > >> Hi Malte, >> >> I don’t see anything off in your thread dump. >> >> Thread qtp23808661-65 is not doing anything. >> None of the other threads is doing anything relevant either. >> >> Thread qtp23808661-63 is waiting for the page to unlock. >> >> So that points in the direction of something like this: >> >> T1 qtp23808661-65 handles a page request for page 0 >> T1 qtp23808661-65 locks the page and tries to serialize it, fails, and >> does >> not unlock the page >> T2 qtp23808661-63 handles a page request for page 0, finds it, but throws >> after 60 seconds because it is still locked >> >> Try to add the following when starting your JVM: >> >> --add-opens=java.base/java.lang=ALL-UNNAMED \ >> --add-opens=java.base/java.io=ALL-UNNAMED \ >>
Re: Problems after Upgrade from older Version with Ajax
On 19/11/2025 11:14 pm, Malte wrote: Hello! I’ve picked up an old project again and upgraded it from version 6 to 10.1. You're a lot more adventurous that we were - we migrated from 6 -> 7 first with the aim to go from 7->8 then 8->9 over time. Apart from a few small changes the 6->7 went very smoothly and we didn't experience any runtime issues ... and we're still on 7! ;) Migrating 7->8 will require a lot more code changes, especially in the area of AJAX comms because most method signatures that take an AjaxRequestTarget have changed - and we have a LOT of them in our code base. But... hats off to you for jumping from 6 -> 10 in one step - that would be quite a challenge! Regards, Chrisco - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Problems after Upgrade from older Version with Ajax
Hi Malte,
I don’t see anything off in your thread dump.
Thread qtp23808661-65 is not doing anything.
None of the other threads is doing anything relevant either.
Thread qtp23808661-63 is waiting for the page to unlock.
So that points in the direction of something like this:
T1 qtp23808661-65 handles a page request for page 0
T1 qtp23808661-65 locks the page and tries to serialize it, fails, and does
not unlock the page
T2 qtp23808661-63 handles a page request for page 0, finds it, but throws
after 60 seconds because it is still locked
Try to add the following when starting your JVM:
--add-opens=java.base/java.lang=ALL-UNNAMED \
--add-opens=java.base/java.io=ALL-UNNAMED \
--add-opens=java.base/java.util=ALL-UNNAMED \
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED \
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
(This is the default add-opens statements that Apache Tomcat adds for Java
>= 9)
That will fix your serialization error ("module java.base does not "opens
java.io" to unnamed module @1479e3f”) for now.
Can you check if that (also) fixes your page locking issue?
Normally a serialization issue should not lead to a “lost” lock on the page
(just browsing PageAccessSynchronizer I see that semantically this should
never happen: in the nested IPageManager implementation, in detach(), it
unlocks all pages in a “finally” block).
But if that happens here, it’s something to debug after confirming.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 20 nov 2025, 10:52:30 schreef Malte :
> Here is a thread dump attached that I created in the IDE. I hope it's
> correct—I haven't needed something like this before.
> The error message is:
>
> *org.apache.wicket.page.PageLockedException: This thread qtp23808661-65
> holds the lock to page 0*
>
> The serialization issue still exists; I still need to think about how I’m
> going to solve that.
>
>
> Am Do., 20. Nov. 2025 um 10:28 Uhr schrieb Bas Gooren >:
>
>> Hi Malte,
>>
>> Your serialization error is something to investigate, yes. But I doubt
>> that
>> is what locks the page so long.
>> It does look like serialization is broken because you upgraded to a more
>> modern JVM, which requires opening modules for serialization.
>> (Wicket 6.x was targeting java 6, wicket 10 targets java 17).
>>
>> As Martin suggested: probably a good idea to look at a thread dump right
>> after you click on the button.
>>
>> After looking again at your first message, I see that your button click
>> request is the one that submits the search form in your topbar [1]. It
>> waits for 1 minute and then times out as it cannot get a lock on the page.
>>
>> That means that something else holds the lock on the page.
>>
>> I would click on the button, and then make a thread dump [2]. That will
>> give you an idea of what all threads are doing and when you get another
>> exception reported like "PageLockedException: This thread qtp5287243-65
>> holds the lock to page 0”, you can look at what that thread is/was doing
>> to
>> hold the page lock.
>>
>> In your first message the thread ids were missing from the logs, so we
>> can’t see what kind of request thread qtp5287243-65 was processing.
>> In your second message the page lock exception doesn’t make any sense:
>>
>> "qtp27122009-55 holds the lock to page 0” => in your logs we can see
>> that qtp27122009-55 ends the request at 5108, while your Ajax request
>> (qtp27122009-54) doesn’t start until 66973.
>>
>> => That would point in the direction of something *after* the request that
>> holds a lock on the page. Which could certainly be the serializer.
>> But that is easy to confirm with the thread dump 🙂
>>
>> 1]
>>
>> ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=a&search_form_submit=1&_=1763552644294
>>
>> 2] find the relevant pid by running “jps” and then run “jstack -l "
>>
>> Met vriendelijke groet,
>> Kind regards,
>>
>> Bas Gooren
>>
>>
>> Op 20 nov 2025, 10:05:06 schreef Malte > .invalid
>> >:
>>
>> > The log output above was one I produced myself using System.out in the
>> > request cycle. I just realized that my logger wasn’t configured
>> correctly
>> > and therefore didn’t log anything. After configuring it properly, I
>> noticed
>> > this output:
>> >
>> > SerializableChecker not available
>> > java.lang.reflect.InaccessibleObjectException: Unable to make static
>> > java.io.ObjectStreamClass
>> > java.io.ObjectStreamClass.lookup(java.lang.Class,boolean) accessible:
>> > module java.base does not "opens java.io" to unnamed module @1479e3f
>> > at
>> >
>> >
>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
>> > at
>> >
>> >
>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>> > at
>> >
>> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:200)
>> > at java.base/java.lang.reflect.Method.setAccessible(Method.java:194)
>> > at
>> >
>> >
>>
Re: Problems after Upgrade from older Version with Ajax
Hi Malte, Your serialization error is something to investigate, yes. But I doubt that is what locks the page so long. It does look like serialization is broken because you upgraded to a more modern JVM, which requires opening modules for serialization. (Wicket 6.x was targeting java 6, wicket 10 targets java 17). As Martin suggested: probably a good idea to look at a thread dump right after you click on the button. After looking again at your first message, I see that your button click request is the one that submits the search form in your topbar [1]. It waits for 1 minute and then times out as it cannot get a lock on the page. That means that something else holds the lock on the page. I would click on the button, and then make a thread dump [2]. That will give you an idea of what all threads are doing and when you get another exception reported like "PageLockedException: This thread qtp5287243-65 holds the lock to page 0”, you can look at what that thread is/was doing to hold the page lock. In your first message the thread ids were missing from the logs, so we can’t see what kind of request thread qtp5287243-65 was processing. In your second message the page lock exception doesn’t make any sense: "qtp27122009-55 holds the lock to page 0” => in your logs we can see that qtp27122009-55 ends the request at 5108, while your Ajax request (qtp27122009-54) doesn’t start until 66973. => That would point in the direction of something *after* the request that holds a lock on the page. Which could certainly be the serializer. But that is easy to confirm with the thread dump 🙂 1] ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=a&search_form_submit=1&_=1763552644294 2] find the relevant pid by running “jps” and then run “jstack -l " Met vriendelijke groet, Kind regards, Bas Gooren Op 20 nov 2025, 10:05:06 schreef Malte : > The log output above was one I produced myself using System.out in the > request cycle. I just realized that my logger wasn’t configured correctly > and therefore didn’t log anything. After configuring it properly, I noticed > this output: > > SerializableChecker not available > java.lang.reflect.InaccessibleObjectException: Unable to make static > java.io.ObjectStreamClass > java.io.ObjectStreamClass.lookup(java.lang.Class,boolean) accessible: > module java.base does not "opens java.io" to unnamed module @1479e3f > at > > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) > at > > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) > at > java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:200) > at java.base/java.lang.reflect.Method.setAccessible(Method.java:194) > at > > org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.(CheckingObjectOutputStream.java:253) > at > > org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:387) > at > > java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346) > at > > org.apache.wicket.serialize.java.JavaSerializer.serialize(JavaSerializer.java:97) > at > > org.apache.wicket.pageStore.SerializingPageStore.addPage(SerializingPageStore.java:80) > at > > org.apache.wicket.pageStore.CachingPageStore.addPage(CachingPageStore.java:73) > at > > org.apache.wicket.pageStore.RequestPageStore.detach(RequestPageStore.java:114) > at org.apache.wicket.page.PageManager.detach(PageManager.java:91) > at org.apache.wicket.Application$2.onDetach(Application.java:1589) > at > > org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) > at > > org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) > at > > org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:121) > at > > org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:145) > at > > org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:114) > at > > org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) > at > > org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:673) > at > org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:628) > at > > org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:285) > at > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:208) > at > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:307) > at > org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) > at > > org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1592) > at > >
Re: Problems after Upgrade from older Version with Ajax
The log output above was one I produced myself using System.out in the request cycle. I just realized that my logger wasn’t configured correctly and therefore didn’t log anything. After configuring it properly, I noticed this output: SerializableChecker not available java.lang.reflect.InaccessibleObjectException: Unable to make static java.io.ObjectStreamClass java.io.ObjectStreamClass.lookup(java.lang.Class,boolean) accessible: module java.base does not "opens java.io" to unnamed module @1479e3f at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:200) at java.base/java.lang.reflect.Method.setAccessible(Method.java:194) at org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream.(CheckingObjectOutputStream.java:253) at org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:387) at java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346) at org.apache.wicket.serialize.java.JavaSerializer.serialize(JavaSerializer.java:97) at org.apache.wicket.pageStore.SerializingPageStore.addPage(SerializingPageStore.java:80) at org.apache.wicket.pageStore.CachingPageStore.addPage(CachingPageStore.java:73) at org.apache.wicket.pageStore.RequestPageStore.detach(RequestPageStore.java:114) at org.apache.wicket.page.PageManager.detach(PageManager.java:91) at org.apache.wicket.Application$2.onDetach(Application.java:1589) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) at org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:121) at org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:145) at org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:114) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:673) at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:628) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:285) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:208) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:307) at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1592) at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1554) at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:807) at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:442) at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575) at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:719) at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1220) at org.eclipse.jetty.server.Handler$Sequence.handle(Handler.java:859) at org.eclipse.jetty.server.Server.handle(Server.java:195) at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:680) at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:411) at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1809) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:614) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:415) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:156) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produce(AdaptiveExecutionStrategy.java:196) at
Re: Problems after Upgrade from older Version with Ajax
On Wed, Nov 19, 2025 at 3:33 PM Malte wrote: > Thank you for the quick response. > > > I’ve tried it again now and had the corresponding thread displayed — this > time with a different name. I’ve also added the thread to the log. > > The thrown exception is this one: > org.apache.wicket.page.PageLockedException: This thread qtp27122009-55 > holds the lock to page 0 > > > Log output: > > qtp27122009-55>>> 3828 onBeginRequest: > qtp27122009-55<<< 3838 onRequestHandlerResolved [10ms]: > RenderPageRequestHandler > qtp27122009-55=== 5108 onEndRequest [1280ms] > I don't know what kind of log file format this is. In your web server stdout you should see a thread dump of all threads. One of the threads should have a name "qtp27122009-55". It stack trace should tell you what exactly hangs. If you run your app on Linux you can also use "kill -3 YOUR_APP_PID" to get the thread dump. > qtp27122009-63>>> 5234 onBeginRequest: ?0 > qtp27122009-63<<< 5234 onRequestHandlerResolved [0ms]: > BufferedResponseRequestHandler > qtp27122009-63=== 5245 onEndRequest [11ms] ?0 > qtp27122009-64>>> 5280 onBeginRequest: css/prisma_style_1600.css > qtp27122009-64=== 5281 onEndRequest [1ms] css/prisma_style_1600.css > qtp27122009-55>>> 5285 onBeginRequest: wic > ket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > qtp27122009-55<<< 5286 onRequestHandlerResolved [1ms]: > ResourceReferenceRequestHandler > qtp27122009-57>>> 5289 onBeginRequest: > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > qtp27122009-57<<< 5290 onRequestHandlerResolved [1ms]: > ResourceReferenceRequestHandler > qtp27122009-57=== 5293 onEndRequest [4ms] > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > qtp27122009-58>>> 5293 onBeginRequest: > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > qtp27122009-55=== 5293 onEndRequest [0ms] > wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > qtp27122009-58<<< 5293 onRequestHandlerResolved [0ms]: > ResourceReferenceRequestHandler > qtp27122009-58=== 5295 onEndRequest [2ms] > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > qtp27122009-70>>> 5307 onBeginRequest: > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > qtp27122009-70<<< 5307 onRequestHandlerResolved [0ms]: > ResourceReferenceRequestHandler > qtp27122009-58>>> 5308 onBeginRequest: js/prisma.min.js > qtp27122009-58=== 5309 onEndRequest [1ms] js/prisma.min.js > qtp27122009-70=== 5309 onEndRequest [1ms] > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > qtp27122009-63>>> 5323 onBeginRequest: css/prisma_style_768.css > qtp27122009-63=== 5323 onEndRequest [0ms] css/prisma_style_768.css > qtp27122009-65>>> 5335 onBeginRequest: css/prisma_style_1024_portrait.css > qtp27122009-65=== 5335 onEndRequest [0ms] > css/prisma_style_1024_portrait.css > qtp27122009-66>>> 5347 onBeginRequest: css/prisma_style_1024.css > qtp27122009-66=== 5347 onEndRequest [0ms] css/prisma_style_1024.css > qtp27122009-63>>> 5359 onBeginRequest: css/prisma_style_1366.css > qtp27122009-63=== 5359 onEndRequest [0ms] css/prisma_style_1366.css > qtp27122009-56>>> 5364 onBeginRequest: css/prisma_style_1440.css > qtp27122009-56=== 5365 onEndRequest [1ms] css/prisma_style_1440.css > qtp27122009-66>>> 5386 onBeginRequest: fonts/NotesWeb-RegularTf.woff > qtp27122009-66=== 5386 onEndRequest [0ms] fonts/NotesWeb-RegularTf.woff > qtp27122009-58>>> 5389 onBeginRequest: fonts/prismaone-icons.woff > qtp27122009-69>>> 5389 onBeginRequest: fonts/NotesWeb-RegularItalicTf.woff > qtp27122009-69=== 5389 onEndRequest [0ms] > fonts/NotesWeb-RegularItalicTf.woff > qtp27122009-58=== 5389 onEndRequest [0ms] fonts/prismaone-icons.woff > qtp27122009-54>>> 66973 onBeginRequest: > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056 > qtp27122009-54<<< 150107 onRequestHandlerResolved [83134ms]: > RenderPageRequestHandler > qtp27122009-54=== 150127 onEndRequest [83154ms] > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056 > qtp27122009-72>>> 151141 onBeginRequest: wicket/page?1 > > Here is the thread in the IDE when it becomes idle: > [image: grafik.png] > > By the way, this is my code in Webapplication#init that generates the logs: > > final long appStartTime = System.currentTimeMillis(); > > getRequestCycleListeners().add(new IRequestCycleListener()
Re: Problems after Upgrade from older Version with Ajax
I’ve inserted the image again directly as a file. Hopefully it’s visible now. For testing, I’m running it in the IDE and set a breakpoint at *onSubmit*, but it never gets there. To rule out that it’s caused by some forgotten breakpoint, I also started it without the debugger. The problem occurs there as well. -- Am Mi., 19. Nov. 2025 um 15:45 Uhr schrieb Bas Gooren : > Hi Malte, > > Your image is not working… > > But we can see in your logs that the following request hangs for 83 > seconds: > > qtp27122009-54=== 150127 onEndRequest [83154ms] > > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056 > > Since you are working with an IDE: do you have an active breakpoint in your > search form or search code? > 83 seconds seems way too long for a search request… Unless the IDE hits a > breakpoint and is waiting for you to decide what to do. > > Or perhaps your search request hangs until it hits a timeout? > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > > Op 19 nov 2025, 14:33:17 schreef Malte .invalid > >: > > > Thank you for the quick response. > > > > > > I’ve tried it again now and had the corresponding thread displayed — this > > time with a different name. I’ve also added the thread to the log. > > > > The thrown exception is this one: > > org.apache.wicket.page.PageLockedException: This thread qtp27122009-55 > > holds the lock to page 0 > > > > > > Log output: > > > > qtp27122009-55>>> 3828 onBeginRequest: > > qtp27122009-55<<< 3838 onRequestHandlerResolved [10ms]: > > RenderPageRequestHandler > > qtp27122009-55=== 5108 onEndRequest [1280ms] > > qtp27122009-63>>> 5234 onBeginRequest: ?0 > > qtp27122009-63<<< 5234 onRequestHandlerResolved [0ms]: > > BufferedResponseRequestHandler > > qtp27122009-63=== 5245 onEndRequest [11ms] ?0 > > qtp27122009-64>>> 5280 onBeginRequest: css/prisma_style_1600.css > > qtp27122009-64=== 5281 onEndRequest [1ms] css/prisma_style_1600.css > > qtp27122009-55>>> 5285 onBeginRequest: wic > > > ket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > > qtp27122009-55<<< 5286 onRequestHandlerResolved [1ms]: > > ResourceReferenceRequestHandler > > qtp27122009-57>>> 5289 onBeginRequest: > > > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > > qtp27122009-57<<< 5290 onRequestHandlerResolved [1ms]: > > ResourceReferenceRequestHandler > > qtp27122009-57=== 5293 onEndRequest [4ms] > > > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > > qtp27122009-58>>> 5293 onBeginRequest: > > > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > > qtp27122009-55=== 5293 onEndRequest [0ms] > > > wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > > qtp27122009-58<<< 5293 onRequestHandlerResolved [0ms]: > > ResourceReferenceRequestHandler > > qtp27122009-58=== 5295 onEndRequest [2ms] > > > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > > qtp27122009-70>>> 5307 onBeginRequest: > > > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > > qtp27122009-70<<< 5307 onRequestHandlerResolved [0ms]: > > ResourceReferenceRequestHandler > > qtp27122009-58>>> 5308 onBeginRequest: js/prisma.min.js > > qtp27122009-58=== 5309 onEndRequest [1ms] js/prisma.min.js > > qtp27122009-70=== 5309 onEndRequest [1ms] > > > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > > qtp27122009-63>>> 5323 onBeginRequest: css/prisma_style_768.css > > qtp27122009-63=== 5323 onEndRequest [0ms] css/prisma_style_768.css > > qtp27122009-65>>> 5335 onBeginRequest: css/prisma_style_1024_portrait.css > > qtp27122009-65=== 5335 onEndRequest [0ms] > > css/prisma_style_1024_portrait.css > > qtp27122009-66>>> 5347 onBeginRequest: css/prisma_style_1024.css > > qtp27122009-66=== 5347 onEndRequest [0ms] css/prisma_style_1024.css > > qtp27122009-63>>> 5359 onBeginRequest: css/prisma_style_1366.css > > qtp27122009-63=== 5359 onEndRequest [0ms] css/prisma_style_1366.css > > qtp27122009-56>>> 5364 onBeginRequest: css/prisma_style_1440.css > > qtp27122009-56=== 5365 onEndRequest [1ms] css/prisma_style_1440.css > > qtp27122009-66>>> 5386 onBeginRequest: fonts/NotesWeb-RegularTf.woff > > qtp27122009-66=== 5386 onEndRequest [0ms] fonts/NotesWeb-RegularTf.woff > > qtp27122009-58>>> 5389 onBeginRequest: fonts/prismaone-icons.woff > > qtp27122009-69>>> 5389 onBeginRequest: > fonts/NotesWeb-RegularItalicTf.woff > >
Re: Problems after Upgrade from older Version with Ajax
Hi Malte, Your image is not working… But we can see in your logs that the following request hangs for 83 seconds: qtp27122009-54=== 150127 onEndRequest [83154ms] ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056 Since you are working with an IDE: do you have an active breakpoint in your search form or search code? 83 seconds seems way too long for a search request… Unless the IDE hits a breakpoint and is waiting for you to decide what to do. Or perhaps your search request hangs until it hits a timeout? Met vriendelijke groet, Kind regards, Bas Gooren Op 19 nov 2025, 14:33:17 schreef Malte : > Thank you for the quick response. > > > I’ve tried it again now and had the corresponding thread displayed — this > time with a different name. I’ve also added the thread to the log. > > The thrown exception is this one: > org.apache.wicket.page.PageLockedException: This thread qtp27122009-55 > holds the lock to page 0 > > > Log output: > > qtp27122009-55>>> 3828 onBeginRequest: > qtp27122009-55<<< 3838 onRequestHandlerResolved [10ms]: > RenderPageRequestHandler > qtp27122009-55=== 5108 onEndRequest [1280ms] > qtp27122009-63>>> 5234 onBeginRequest: ?0 > qtp27122009-63<<< 5234 onRequestHandlerResolved [0ms]: > BufferedResponseRequestHandler > qtp27122009-63=== 5245 onEndRequest [11ms] ?0 > qtp27122009-64>>> 5280 onBeginRequest: css/prisma_style_1600.css > qtp27122009-64=== 5281 onEndRequest [1ms] css/prisma_style_1600.css > qtp27122009-55>>> 5285 onBeginRequest: wic > ket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > qtp27122009-55<<< 5286 onRequestHandlerResolved [1ms]: > ResourceReferenceRequestHandler > qtp27122009-57>>> 5289 onBeginRequest: > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > qtp27122009-57<<< 5290 onRequestHandlerResolved [1ms]: > ResourceReferenceRequestHandler > qtp27122009-57=== 5293 onEndRequest [4ms] > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > qtp27122009-58>>> 5293 onBeginRequest: > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > qtp27122009-55=== 5293 onEndRequest [0ms] > wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > qtp27122009-58<<< 5293 onRequestHandlerResolved [0ms]: > ResourceReferenceRequestHandler > qtp27122009-58=== 5295 onEndRequest [2ms] > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > qtp27122009-70>>> 5307 onBeginRequest: > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > qtp27122009-70<<< 5307 onRequestHandlerResolved [0ms]: > ResourceReferenceRequestHandler > qtp27122009-58>>> 5308 onBeginRequest: js/prisma.min.js > qtp27122009-58=== 5309 onEndRequest [1ms] js/prisma.min.js > qtp27122009-70=== 5309 onEndRequest [1ms] > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > qtp27122009-63>>> 5323 onBeginRequest: css/prisma_style_768.css > qtp27122009-63=== 5323 onEndRequest [0ms] css/prisma_style_768.css > qtp27122009-65>>> 5335 onBeginRequest: css/prisma_style_1024_portrait.css > qtp27122009-65=== 5335 onEndRequest [0ms] > css/prisma_style_1024_portrait.css > qtp27122009-66>>> 5347 onBeginRequest: css/prisma_style_1024.css > qtp27122009-66=== 5347 onEndRequest [0ms] css/prisma_style_1024.css > qtp27122009-63>>> 5359 onBeginRequest: css/prisma_style_1366.css > qtp27122009-63=== 5359 onEndRequest [0ms] css/prisma_style_1366.css > qtp27122009-56>>> 5364 onBeginRequest: css/prisma_style_1440.css > qtp27122009-56=== 5365 onEndRequest [1ms] css/prisma_style_1440.css > qtp27122009-66>>> 5386 onBeginRequest: fonts/NotesWeb-RegularTf.woff > qtp27122009-66=== 5386 onEndRequest [0ms] fonts/NotesWeb-RegularTf.woff > qtp27122009-58>>> 5389 onBeginRequest: fonts/prismaone-icons.woff > qtp27122009-69>>> 5389 onBeginRequest: fonts/NotesWeb-RegularItalicTf.woff > qtp27122009-69=== 5389 onEndRequest [0ms] > fonts/NotesWeb-RegularItalicTf.woff > qtp27122009-58=== 5389 onEndRequest [0ms] fonts/prismaone-icons.woff > qtp27122009-54>>> 66973 onBeginRequest: > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056 > qtp27122009-54<<< 150107 onRequestHandlerResolved [83134ms]: > RenderPageRequestHandler > qtp27122009-54=== 150127 onEndRequest [83154ms] > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056 > qtp27122009-72>>>
Re: Problems after Upgrade from older Version with Ajax
Thank you for the quick response.
I’ve tried it again now and had the corresponding thread displayed — this
time with a different name. I’ve also added the thread to the log.
The thrown exception is this one:
org.apache.wicket.page.PageLockedException: This thread qtp27122009-55
holds the lock to page 0
Log output:
qtp27122009-55>>> 3828 onBeginRequest:
qtp27122009-55<<< 3838 onRequestHandlerResolved [10ms]:
RenderPageRequestHandler
qtp27122009-55=== 5108 onEndRequest [1280ms]
qtp27122009-63>>> 5234 onBeginRequest: ?0
qtp27122009-63<<< 5234 onRequestHandlerResolved [0ms]:
BufferedResponseRequestHandler
qtp27122009-63=== 5245 onEndRequest [11ms] ?0
qtp27122009-64>>> 5280 onBeginRequest: css/prisma_style_1600.css
qtp27122009-64=== 5281 onEndRequest [1ms] css/prisma_style_1600.css
qtp27122009-55>>> 5285 onBeginRequest: wic
ket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js
qtp27122009-55<<< 5286 onRequestHandlerResolved [1ms]:
ResourceReferenceRequestHandler
qtp27122009-57>>> 5289 onBeginRequest:
wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js
qtp27122009-57<<< 5290 onRequestHandlerResolved [1ms]:
ResourceReferenceRequestHandler
qtp27122009-57=== 5293 onEndRequest [4ms]
wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js
qtp27122009-58>>> 5293 onBeginRequest:
wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js
qtp27122009-55=== 5293 onEndRequest [0ms]
wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js
qtp27122009-58<<< 5293 onRequestHandlerResolved [0ms]:
ResourceReferenceRequestHandler
qtp27122009-58=== 5295 onEndRequest [2ms]
wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js
qtp27122009-70>>> 5307 onBeginRequest:
wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js
qtp27122009-70<<< 5307 onRequestHandlerResolved [0ms]:
ResourceReferenceRequestHandler
qtp27122009-58>>> 5308 onBeginRequest: js/prisma.min.js
qtp27122009-58=== 5309 onEndRequest [1ms] js/prisma.min.js
qtp27122009-70=== 5309 onEndRequest [1ms]
wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js
qtp27122009-63>>> 5323 onBeginRequest: css/prisma_style_768.css
qtp27122009-63=== 5323 onEndRequest [0ms] css/prisma_style_768.css
qtp27122009-65>>> 5335 onBeginRequest: css/prisma_style_1024_portrait.css
qtp27122009-65=== 5335 onEndRequest [0ms] css/prisma_style_1024_portrait.css
qtp27122009-66>>> 5347 onBeginRequest: css/prisma_style_1024.css
qtp27122009-66=== 5347 onEndRequest [0ms] css/prisma_style_1024.css
qtp27122009-63>>> 5359 onBeginRequest: css/prisma_style_1366.css
qtp27122009-63=== 5359 onEndRequest [0ms] css/prisma_style_1366.css
qtp27122009-56>>> 5364 onBeginRequest: css/prisma_style_1440.css
qtp27122009-56=== 5365 onEndRequest [1ms] css/prisma_style_1440.css
qtp27122009-66>>> 5386 onBeginRequest: fonts/NotesWeb-RegularTf.woff
qtp27122009-66=== 5386 onEndRequest [0ms] fonts/NotesWeb-RegularTf.woff
qtp27122009-58>>> 5389 onBeginRequest: fonts/prismaone-icons.woff
qtp27122009-69>>> 5389 onBeginRequest: fonts/NotesWeb-RegularItalicTf.woff
qtp27122009-69=== 5389 onEndRequest [0ms]
fonts/NotesWeb-RegularItalicTf.woff
qtp27122009-58=== 5389 onEndRequest [0ms] fonts/prismaone-icons.woff
qtp27122009-54>>> 66973 onBeginRequest:
?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056
qtp27122009-54<<< 150107 onRequestHandlerResolved [83134ms]:
RenderPageRequestHandler
qtp27122009-54=== 150127 onEndRequest [83154ms]
?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=b&search_form_submit=1&_=1763558058056
qtp27122009-72>>> 151141 onBeginRequest: wicket/page?1
Here is the thread in the IDE when it becomes idle:
[image: grafik.png]
By the way, this is my code in Webapplication#init that generates the logs:
final long appStartTime = System.currentTimeMillis();
getRequestCycleListeners().add(new IRequestCycleListener() {
private long startTime;
@Override
public void onBeginRequest(RequestCycle cycle) {
startTime = System.currentTimeMillis();
System.out.println(Thread.currentThread().getName() + ">>> "+
getTimeSinceAppStart() +" onBeginRequest: " +
cycle.getRequest().getUrl() );
}
@Override
public void onRequestHandlerResolved(RequestCycle cycle,
IRequestHandler handler) {
long duration = System.currentTimeMillis() - startTime;
System.out.println(Thread.currentThread().getName() +
Re: Problems after Upgrade from older Version with Ajax
Hi, Please search for qtp5287243-65 in your logs. This is the id of the thread that received a http request but did not respond in 1 min. It seems to hand on some operation. On Wed, Nov 19, 2025 at 2:14 PM Malte wrote: > Hello! > > I’ve picked up an old project again and upgraded it from version 6 to > 10.1. Now I’m running into an issue where Ajax no longer works, which > renders my application unusable. > > Since I haven’t worked on this project for quite some time, I’m not really > familiar with the Wicket system anymore. Maybe someone can give me a hint > about where I should continue looking for the cause of this error. > > The page loads completely, but when I click on the first Ajax button > everything freezes, and after about a minute I get this exception: > > class org.apache.wicket.page.CouldNotLockPageException > org.apache.wicket.page.CouldNotLockPageException: Could not lock page 0. > Attempt lasted PT1M > at > org.apache.wicket.page.DefaultPageLockManager.lockPage(DefaultPageLockManager.java:173) > at > org.apache.wicket.page.PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:72) > [...]at java.base/java.lang.Thread.run(Thread.java:840) > > Caused by: > org.apache.wicket.page.PageLockedException: This thread qtp5287243-65 > holds the lock to page 0 > at sun.nio.ch.WEPoll.wait(Native Method) > [...]at java.lang.Thread.run(Thread.java:840) > > I’ve added some more logging and found the button that is likely causing > the issue. It only overrides onSubmit. However, the breakpoint in the > debugger is never hit. Here is my requestlog (first value is time since > start): > > >>> 5299 onBeginRequest: > <<< 5303 onRequestHandlerResolved [4ms]: RenderPageRequestHandler > === 6471 onEndRequest [1172ms] > >>> 6486 onBeginRequest: ?0 > <<< 6486 onRequestHandlerResolved [0ms]: BufferedResponseRequestHandler > === 6499 onEndRequest [13ms] ?0 > >>> 6546 onBeginRequest: css/prisma_style_1600.css > === 6547 onEndRequest [1ms] css/prisma_style_1600.css > >>> 6547 onBeginRequest: > wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > <<< 6548 onRequestHandlerResolved [1ms]: ResourceReferenceRequestHandler > === 6558 onEndRequest [11ms] > wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-3.7.1-ver-1763474747505.js > >>> 6560 onBeginRequest: > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > <<< 6560 onRequestHandlerResolved [0ms]: ResourceReferenceRequestHandler > === 6562 onEndRequest [2ms] > wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-1763474747505.js > >>> 6578 onBeginRequest: > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > <<< 6578 onRequestHandlerResolved [0ms]: ResourceReferenceRequestHandler > === 6579 onEndRequest [1ms] > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteButtonBehavior/AutocompleteButtonBehavior-ver-1693220747281.js > >>> 6584 onBeginRequest: > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > <<< 6584 onRequestHandlerResolved [0ms]: ResourceReferenceRequestHandler > === 6586 onEndRequest [2ms] > wicket/resource/de.prisma.one.servlet.gui.wicket.guiElements.autocomplete.AutocompleteBehavior/wicket-autocomplete-modified-ver-1693220747283.js > >>> 6586 onBeginRequest: js/prisma.min.js > === 6587 onEndRequest [1ms] js/prisma.min.js > >>> 6600 onBeginRequest: css/prisma_style_768.css > === 6600 onEndRequest [0ms] css/prisma_style_768.css > >>> 6611 onBeginRequest: css/prisma_style_1024_portrait.css > === 6611 onEndRequest [0ms] css/prisma_style_1024_portrait.css > >>> 6622 onBeginRequest: css/prisma_style_1024.css > === 6622 onEndRequest [0ms] css/prisma_style_1024.css > >>> 6633 onBeginRequest: css/prisma_style_1366.css > === 6633 onEndRequest [0ms] css/prisma_style_1366.css > >>> 6642 onBeginRequest: css/prisma_style_1440.css > === 6642 onEndRequest [0ms] css/prisma_style_1440.css > >>> 6647 onBeginRequest: fonts/NotesWeb-RegularTf.woff > === 6647 onEndRequest [0ms] fonts/NotesWeb-RegularTf.woff > >>> 6649 onBeginRequest: fonts/prismaone-icons.woff > >>> 6649 onBeginRequest: fonts/NotesWeb-RegularItalicTf.woff > === 6650 onEndRequest [1ms] fonts/prismaone-icons.woff > === 6650 onEndRequest [1ms] fonts/NotesWeb-RegularItalicTf.woff > >>> 13582 onBeginRequest: > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=a&search_form_submit=1&_=1763552644294 > <<< 73594 onRequestHandlerResolved [60012ms]: RenderPageRequestHandler > === 73610 onEndRequest [60028ms] > ?0-1.0-topbar-search_form-search_form_submit&0-1.-topbar-search_form&search_form_text=a&search_form_submit=1&_=1763552644294 > >>>
