Details
-
Bug
-
Resolution: Fixed
-
Critical
-
14.10.15
-
None
-
Integration
-
High
-
Medium
-
N/A
-
N/A
-
Description
When the PDF export is performed server-side using a headless Chrome, inside a Docker container or not, opening the PDF Export Modal after a Chrome restart can lead to an infinite loading. This has been noticed in our automated functional tests, when both XWiki (the servlet engine) and Chrome run inside a Docker container. But I'm pretty sure this can happen in other setups too.
The root problem is that the library we rely on to talk with the remote headless Chrome (https://github.com/kklisura/chrome-devtools-java-client) is using Java's HttpURLConnection to make the HTTP requests without setting any timeout. This means the HTTP requests we make to the remote headless Chrome can hang indefinitely or for a very long time.
Note that we tried setting (in various ways) sun.net.client.defaultConnectTimeout and sun.net.client.defaultReadTimeout as per https://bluxte.net/musings/2008/08/25/dont-forget-set-javaneturl-default-timeouts/ but it didn't help. In the end we think the best is to make these HTTP requests in a separate thread using an ExecutorService and to use a timeout when retrieving the Future results.
Attachments
Issue Links
- is related to
-
XWIKI-21174 The PDF export fails after the remote headless Chrome is restarted
- Closed