-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need Support for Async implimentation for SOAP calls. #636
Comments
@sreekar12 Not sure if it may be helpful, but have a look at the code posted here: #4 (comment) |
@shumonsharif How to extract an object from Uni without blocking method (ex: Without join() or get()) |
Hi @sreekar12 - Your question is unrelated to the extension, but I believe you may be able to find some answers on SO, for example here. |
@shumonshariff Sorry, some additional context may help. The code is attempting to make several asynchronous parallel backend calls and aggregate the results. The current cxf SOAP implementation seems to require a join on the completion stages which is a blocking implementation. So the question is , how can the calls be made without blocking. Sreekar referred to Uni because most quarkus extensions work with Unis, the question though is how can the SOAP calls be made in parallel in a non-blocking way. This is specific to CXF SOAP as it is , among the many other implementations of parallel asynchronous calls using quarkus extension libraries, the only we as yet aren't able to figure out how to make in a non-blocking manner. |
Here's another description of the problem. The Quarkus CXF extension does not currently support asynchronous response types in the service interface and need to convert async types (Uni, Completion or Future) to standard response types. This conversion results in the async type to block until backside responses are returned. |
I tried using the @UseAsyncMethod annotation, https://cxf.apache.org/javadoc/latest-3.2.x/org/apache/cxf/annotations/UseAsyncMethod.html The async methods I have implemented per the link above are not called. If the async methods were called I would also expect them to be called on the event-loop-thread
|
@tbkahuna48 Did you or Sreekar look at the example provided in my first comment? That example demonstrates exactly what you are describing? In case it doesn't address your use cases appropriately, could you kindly provide a small reproducer that shows the issue you are facing? |
@linktech1 The I don't believe we've ever tested the |
Yes. We are providing a service that calls other services. We have the the backend service clients being called asynchronously (they return Futures) but we also want the frontside service implementation to also be non-blocking. Looking for the same support as the Quarkus Rest services where the service is completely non-blocking and runs entirely on the vertex-event-loop. |
Anything on Quarkus CXF supporting service provider interfaces with non-blocking async behavior that runs on the vertex-io-thread? |
@linktech1 I haven't had much time to look into this, and likely won't any time soon ... My take is that this is going to be a fairly major effort, and I don't believe the JAX-WS spec will allow us to mimic the same features / patterns as the Quarkus REST services. We may at most be able to possibly integrate the |
I think the @UseAsyncMethod feature would work if the event-loop-thread is used. Async should be disabled if Quarkus detects other blocking code. |
Thanks for reaching out, @sreekar12, @linktech1 and @tbkahuna48. Would adding a proper support for |
The requirement is to enable Quarkus reactive capability and not spin up any additional worker threads (run on the event loop) if the operation flow is non blocking. It looks like the current implementation creates a new Thread for the ServerAsyncResponse in this example: https://cxf.apache.org/javadoc/latest/org/apache/cxf/annotations/UseAsyncMethod.html
We would like to see a Uni or CompletionStage be used to be consistent with Quarkus reactive return types.
Cheers,
Keith Link
***@***.***
… On Aug 9, 2023, at 4:03 PM, Peter Palaga ***@***.***> wrote:
Thanks for reaching out, @sreekar12 <https://github.com/sreekar12>, @linktech1 <https://github.com/linktech1> and @tbkahuna48 <https://github.com/tbkahuna48>.
Would adding a proper support for @UseAsyncMethod solve your needs?
—
Reply to this email directly, view it on GitHub <#636 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSXQG547UTTM5ZGJR6XTXTXUPUI3ANCNFSM6AAAAAASVYY6DA>.
You are receiving this because you were mentioned.
|
SOAP calls are not accepting as Uni as return type. Could you please help us any approach to make SOAP calls as Async.
For now i was using return type as Java class instead of Uni. For converting Uni to Java class i was using join() OR get().
Note: Join() and get() blocks until it gives response.
Could you please suggest any approach instead of above note....
The text was updated successfully, but these errors were encountered: