UPD: after spending some time debugging I found the place where it’s actually blocking.
It’s TapestrySessionFactoryImpl.acquireWriteLock() method and, specifically, this part: lock.writeLock().lock(); perthreadManager.addThreadCleanupCallback(new Runnable() { public void run() { // This is the only way a write lock is unlocked, so no check is needed. lock.writeLock().unlock(); } }); I’m using servlet filter to perform user session authentication, and ApplicationStateManager to check the current session. Now, Tapestry’s SessionImpl is like this: public Object getAttribute(String name) { lock.acquireWriteLock(); return session.getAttribute(name); } Meaning, when I’m retrieving session attribute at the beginning of the request, the lock won’t be released until the request is completed and PerThreadManager cleanup is run. Is that a known issue? Was it made this way for a reason? (I’m on 5.4-beta6 for several reasons). On Sun, Mar 18, 2018 at 2:30 PM, Ilya Obshadko <xf...@xfyre.com> wrote: > Hi everyone, > > I’m struggling to understand the cause of the following issue: > > - my Tapestry application generates certain PDF files using Apache FOP and > Saxon > - when PDF generator process is started, other requests to that instance > are blocked until it’s finished > - moving FOP processing to a new thread using ParallelExecutor.invoke() > doesn’t seem to affect anything > > Any ideas why? > > I had a hypothesis that FOP processing actually blocks the whole thing > because of AWT usage, but couldn’t find any confirmations yet. > > -- > Ilya Obshadko > > > > -- Ilya Obshadko