Problem is that file upload uses the Blob Upload for Batch Processing mechanism which happens in 2 steps:
- Upload: call to /site/automation/batch/upload
- Execute: call to /site/automation/batch/execute
See https://github.com/nuxeo/nuxeo/blob/master/nuxeo-features/nuxeo-automation/nuxeo-automation-server/src/main/java/org/nuxeo/ecm/automation/server/jaxrs/batch/BatchResource.java about the batch JAX-RS resource.
Let's say the Nuxeo instance is configured with a cluster of 2 nodes A and B. If the upload request hits A and the execute request hits B then we'll have the following error:
This is from what SUPNXP-13263 was suffering.
- Make Drive always hit the same node by configuring a request filter in the load balancer based on the User-Agent: "Nuxeo-Drive/<version>"
See https://jira.nuxeo.com/browse/SUPNXP-13263?focusedCommentId=223223&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-223223 for an Apache configuration sample.
=> This is a workaround as Drive cannot benefit of the clustering.
- Configure a header affinity on 'X-Authentication-Token' which is passed in every Drive request, but this seems impossible with Apache mod_jk.
- Configure a cookie affinity with mod_proxy, see http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html, but might need to transform the token authentication header to a cookie, see http://httpd.apache.org/docs/2.4/mod/mod_headers.html, and if not possible check http://httpd.apache.org/docs/2.4/mod/mod_env.html to see if we can do a header -> env -> cookie transformation...
- Make Drive create a false JSESSIONID cookie (randomly generated at startup) to work with any sticky session configuration as detailed in
=> Probably the best solution!