PDF rendering in background blocks other requests

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

PDF rendering in background blocks other requests

Ilya Obshadko
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
Reply | Threaded
Open this post in threaded view
|

Re: PDF rendering in background blocks other requests

Dmitry Gusev
Take a thread dump and see what other blocked requests are waiting for?

On Sunday, March 18, 2018, Ilya Obshadko <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: PDF rendering in background blocks other requests

Ilya Obshadko
In reply to this post by Ilya Obshadko
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: PDF rendering in background blocks other requests

Ilya Obshadko-2
In reply to this post by Dmitry Gusev
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 <[hidden email]>
wrote:

> Take a thread dump and see what other blocked requests are waiting for?
>
> On Sunday, March 18, 2018, Ilya Obshadko <[hidden email]> 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