dylanpiergies commented on code in PR #9592:
URL: https://github.com/apache/camel/pull/9592#discussion_r1143978501
##########
components/camel-azure/camel-azure-servicebus/src/main/java/org/apache/camel/component/azure/servicebus/ServiceBusConsumer.java:
##########
@@ -145,6 +145,9 @@ private void onEventListener(final
ServiceBusReceivedMessage message) {
// use default consumer callback
AsyncCallback cb = defaultConsumerCallback(exchange, true);
getAsyncProcessor().process(exchange, cb);
+ if (exchange.getException() != null) {
Review Comment:
There is, but it requires the `ServiceBusReceivedMessage` to be in scope and
it returns a `Mono<Void>` to which we need to subscribe in order for it to
execute. The way things are right now, an invocation to
`ServiceBusReceiverAsyncClientWrapper#complete` or
`ServiceBusReceiverAsyncClientWrapper#abandon` would return a `Mono<Void>` on
which we'd then have to invoke `block()`.
I've looked into this problem in some depth, and I'm still looking for the
"right" approach to addressing this. I kinda feel like using the async client
isn't a very good fit, because we're then dealing with a component that is
reactive from the outset and I don't think there's any framework within Camel
for handling this in a clean and intuitive way (although correct me if I'm
wrong).
I understand your point about the result not being valid until the callback
completes, but while I was step debugging I did find that callback was always
being executed before `getAsyncProcessor().process(exchange, cb);` returned.
This probably isn't great either, because `onEventListener` is the processor
for a `Flux` subscription which I believe places it within a reactive context
and it therefore shouldn't block.
So the possible solutions as I see it boil down to:
1. Rewrite the component using the synchronous version of the Azure Service
Bus client so it's more typical of a traditional Camel component.
2. Make changes to ensure the `ServiceBusReceivedMessage` is available to
the callback, remove the `disableAutoComplete` component/endpoint option and
take control of completion/abandonment within the consumer callback. This might
sound like the "right" option on the surface, but I don't see any obvious way
to connect the Reactor subscription to Camel's async mechanisms.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
