Reports/Processes Running in Request-Servicing Thread

Description

During profiling it was noticed that a report that was ran from the home screen executes in the request-servicing thread.  This thread continues to be consumed until the report generation finishes even if the browser is closed.  If the user thinks the application is not responding and does this several times, multiple threads are consumed making the application less responsive and potentially non-responsive if all threads are consumed. See comments for explanation of removal

The same behavior was observed when posting Disbursements from the Payable screen. See the attached stack trace showing several Tomcat threads waiting on a locked VaadinSession where Disbursement posting is running in the servicing thread. After the long-running thread completes, the lock is released and the other threads return to the proper waiting/parked state after completing.

NOTE: In the attached stack trace, thread tomcat-exec-19 is the locking thread. Search for this thread name to see other threads waiting on the lock held by this thread

Environment

None

Attachments

1

caused

depends on

Activity

Christopher Springer April 23, 2018 at 4:41 PM

Modified issue and included explanation. All necessary changes were on issue SV-2

Christopher Springer April 23, 2018 at 4:18 PM

By nature, a streaming response from the server for report generation is sent in the servicing thread. There isn't really a way to get around this since the data is sent as it is generated while servicing the request. The only way to make this run in the background would be to persist the result of the report run and then send that result in response to the request. A better solution to this would probably be to run a scheduled job in the background and let the user download the result/report when it is finished.

Duplicate

Details

Assignee

Reporter

Fix versions

Times Requested

1

Source

120 Eligible

Yes

Affects versions

Priority

Better PDF Exporter

Created March 28, 2018 at 6:37 PM
Updated May 8, 2018 at 12:54 PM
Resolved April 23, 2018 at 4:41 PM