Question

A JavaEE application must process a large number of PDF documents.
The kind of processing is not important but for the sake of clarity we can say that it includes extracting text, converting pages into images, stamping IDs on the first page, printing, saving them to DB.

Incoming PDFs come from a huge variety of suppliers so there is very little control over them (if any).

All operations take place in the background, i.e. there are timers polling inbound channels, retrieving the documents and sending them to processing. No user interaction.

Two top-level java libraries are used to manage PDFs. Due to the PDF specification extension and the extreme spread among PDF generating tools, they can’t possibly cover every possibile flaw, so sometimes they fail to manipulate or even open a document.

Quite unfortunately, they sometimes fail without raising an exception but blocking in an infinite sub-method. This is critical because the polling timer blocks, no more documents are processed, administrators realize that something is wrong too late and -what’s worse- the whole application server must be restarted, which is not easy/fair in a production environment.

So how could the EJB that drives the library understand that the call is blocked and stop the transaction ?

I could start a dedicated thread (without breaking the JavaEE specification) and set a wait with a timeout. The wait ends when either a flag is checked or the timeout is reached. In the latter case the thread is considered blocked, the PDF can be marked as invalid and, for instance, an email alert can be sent.

Does anyone see any alternative -and feasible- solutions ?

Thanks

Answer 1

I’m not sure I fully get what you have described, but IMHO you can either use MDB’s for asynchronous processing (instead of creating separate threads) or run the EJB methods in a transactional context and set the transaction timeout for the method which does the job you described. If the transaction times out you will get an exception you wanted.