Re: PDF rendering in background blocks other requests
Yes, I’ve already found the root cause (described in my previous message). Setting tapestry.session-locking-enabled=false instantly fixes this. However, long-term, I’d prefer to have something like this (pseudocode): lock.safeGet(() -> session.getAttribute(name)); lock.safeSet(() -> session.setAttribute(name, value)); This would of course require rewriting at least SessionImpl and TapestrySessionFactoryImpl to support such semantics. On Sun, Mar 18, 2018 at 3:33 PM, Dmitry Gusev wrote: > Take a thread dump and see what other blocked requests are waiting for? > > On Sunday, March 18, 2018, Ilya Obshadko 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 > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- Ilya Obshadko
Re: PDF rendering in background blocks other requests
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 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
Re: PDF rendering in background blocks other requests
Take a thread dump and see what other blocked requests are waiting for? On Sunday, March 18, 2018, Ilya Obshadko 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 > -- Dmitry Gusev AnjLab Team http://anjlab.com
PDF rendering in background blocks other requests
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
