[ https://issues.apache.org/jira/browse/TUSCANY-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Dritschler updated TUSCANY-3940: ------------------------------------- Attachment: TUSCANY-3940.patch > Change AsyncJDKInvocationHandler to use WorkScheduler directly > -------------------------------------------------------------- > > Key: TUSCANY-3940 > URL: https://issues.apache.org/jira/browse/TUSCANY-3940 > Project: Tuscany > Issue Type: Improvement > Affects Versions: Java-SCA-2.0 > Reporter: Greg Dritschler > Priority: Minor > Attachments: TUSCANY-3940.patch > > > AsyncJDKInvocationHandler obtains an ExecutorService from the WorkScheduler > utility and uses it to schedule asynchronous requests. > AsyncJDKInvocationHandler could just as well use the WorkScheduler utility > directly. This might simplify things for some WorkScheduler providers since > they wouldn't have to support an ExecutorService interface. I am attaching a > patch to make this change. > While working on this, I discovered some other problems which I'm also fixing > in this patch. > 1. When the client passes a callback object, > AsyncJDKInvocationHandler.doInvokeAsyncCallback() invokes the callback > immediately after making the asynchronous request. The callback object > should be invoked when the response is actually available. I am fixing this > by saving the callback object in the future object, > AsyncInvocationFutureImpl. When the response or fault is delivered to the > future (via setResponse() or setFault() or setWrappedFault()), the future > invokes the callback object. > 2. AsyncJDKInvocationHandler.separateThreadInvoker.run() contains a catch > block for a ServiceRuntimeException. If the cause of the > ServiceRuntimeException is NOT a FaultException, the exception is swallowed > for no reason. I changed the code to deliver the exception to the future. > 3. AsyncJDKInvocationHandler.doInvokeSync() contains a wait of 1000 seconds > when a client does a sync invocation of an async service. This is way too > long for a synchronous timeout. Ideally this should be configurable in some > manner, although I don't know how much effort we want to spend on it given > that this is not a desirable invocation pattern. For now I am changing it to > wait 120 seconds. > 4. AsyncFaultWrapper tries to reconstruct a fault using a constructor with a > String argument. If the class does not have such a constructor, this fails. > I have added code to try with the default constructor. > Change #1 exposed an issue in the async-services itest. Service1ClientImpl > uses static variables for the async response and async response fault. After > the first time through, these values may have residual values from the prior > execution and the test will skip waiting on the mutex. The test got away > from this before because of the bad logic in AsyncJDKInvocationHandler: > -- AsyncJDKInvocationHandler.doInvokeAsyncCallback() scheduled a runnable > to invoke the request. It waited for this runnable to complete! > -- The runnable invoked the callback handler after firing the request. The > itest callback handler does a get() on the provided future with an indefinite > timeout. > So the itest was guaranteed that its static variables would be updated. The > test was really running pseudo-synchronously. I changed the itest to use > non-static variables. Now it is falling into the mutex wait for a new > response. I increased the wait time a bit just to be safe. > *** The JCA_11017 compliance test has a very similar problem. It is not > using statics, but it is making multiple requests inside a loop using the > same variables. It uses a CountdownLatch with a value of 1, so after the > first request the latch won't wait anymore. This causes it to not wait for > the exception response for the second request. It got away with this before > for the same reason outlined above; the requests were actually > pseudo-synchronous. The patch does not have a fix for this, so JCA_11017 > will fail until it is somehow corrected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira