Bug 1077305

The fix for this is already available since I've implemented asynchronous REST operations for the (BPMS) ../rest/deployment* calls. It's just a question of copy/pasting that code and modifying it to for the Knowledge Store (/repositories, etc) REST API.

The problem that I increasingly ran into when trying to make these operations is that the underlying components (guvnor modules, uberfire modules) aren't thread-safe or thread-aware. 

In other words, both uberfire and guvnor modules are created with the assumption that all code will run in the same thread and scope as the (REST) request. 


Just to give an idea of the complexity of issues associated with making uberfire and guvnor components thread-safe and thread-aware, see the attached stacktrace. 

The "npe-on-async-uberfire-use-stacktrace.txt" stack trace shows a "Create Project" request being asynchronously executed. The classes in the org.drools.workbench.common.services.rest.async package were developed to asynchronously execute requests. 

The NPE in the stack trace is caused because the guvnor class (ProjectServiceImpl) needs a instance of a (uberfire) class. A @Provider method is called in the Uberfire code, which ends up calling an Errai class (RpcContext). However, the Errai class uses a ThreadLocal variable which would probably normally be set when the (Request/Application) scope is dealt with. For some reason, it's not set in the RequestScope created when the asynchronous (EJB) business method is called to process the "Create Project" request. 

In short, it's probably possible to make the guvnor and uberfire components used by the drools-wb-rest components both thread-safe and thread-aware, but that work lies outside of the scope of this bugzilla, in my opinion. 

For 6.1, at the very least, I'll change the interface so that it behaves as a synchronous REST interface (status 200 returned instead of 202, job status immediately returned, etc.).

Created attachment 889287 [details]
Stacktrace showing problems in errai/uberfire/guvnor

Btw, my rough estimate of the time required to fix the problems above (in uberfire/guvnor) is somewhere between 2 weeks and 3 months, depending on which problems there are.

This has been fixed on master.

This has been fixed in 6.2.x.

Verified in BPMS 6.1.0.ER3

According to comment 3 that: "For 6.1, at the very least, I'll change the interface so that it behaves as a synchronous REST interface (status 200 returned instead of 202, job status immediately returned, etc.)."

The operations return 202 Accepted but I believe it is the right behaviour of the operations.

After all, the real status is in the returned message, for example:

{"jobId":"1420471761248-1","status":"APPROVED","repository":{"name":"NewRepo","description":null,"userName":null,"password":null,"requestType":"new","gitURL":null}}