SmallRye RabbitMQ support in Quarkus

[kdubb]

I'm the author of the "SmallRye Reactive Messaging - RabbitMQ" connector support in quarks 2.4.*. I thought it might be prudent to appraise you of this new support and suggest maybe this extensions README could mention that.

I'm not suggesting this extension is obsolete. This extension provides easy access to the RabbitMQ client whereas the SM-RM-RMQ support uses the Vert.x client. The Vert.x client has a couple of specific design decisions that dictate its use; specifically it uses one connection per connector as opposed to using channels. For example, one of our micro-services translates RabbitMQ events to SSE events for end users. The Vert.x client is too heavyweight for this usage. We use the RabbitMQ library directly for this specific service. For all of our other services we use the SmallRye connector and it works very well.

Some things that are "nicer" about using the connector:

• SmallRye declarative connections
• Dev Services Support Included
• • Topology definitions can be setup in RMQ dev services configuration
• 2.5 or 2.6 will support Vault dynamic credentials for RabbitMQ

Curiously enough I've landed here to see if this extension is of use to us for our one standout service. Thanks for maintaining this extension!

[bpasson]

Thanks for contacting. I'm aware of the "SmallRye Reactive Messaging - RabbitMQ". When I created this I looked at "SmallRye Reactive Messaging" but it just didn't support RabbitMQ good enough. After some discussion with some Quarkus Core developers I opted to create a specific RabbitMQ extension. Had the "SmallRye Reactive Messaging - RabbitMQ" connector existed at the time, this extension would probably never have seen the light.

I can mention the "SmallRye Reactive Messaging - RabbitMQ" connector in the README, but as there is no Quarkus extension to support it listed on https://code.quarkus.io how would developers use it? Are there any plans to create a Quarkus extension which supports the RabbitMQ connector?

This extension is basically here to expose a RabbitMQ client and have you do with it what you wish, pretty low level and lightweight. It fills a gap like you say where the "SmallRye Reactive Messaging - RabbitMQ" is a bit heavy for the job.

I am working on another extension which shamelessly models after the Spring Cloud Messaging paradigm. Which I think is more of a direct contender and probably wouldn't have existed had "SmallRye Reactive Messaging - RabbitMQ" been available at the time.

It is not public yet as I don't have enough time at this moment to work out all the details. The basics are up and running. In essence it works as follows:

@ApplicationScoped
public class Sample {

    // simple bridge to send messages to configured exchange
    @Inject
    StreamBridge streamBridge;

    // receive from queue
    @StreamBean
    public Consumer<MessageA> receive() {
        return msgA -> System.out.println(msgA.toString());
    }

    // receive from queue and drop result on exchange
    @StreamBean
    public Function<MessageA, MessageB> process() {
        return msgA -> MessageB.builder().msg(msgA.toString()).build();
    }

    // drop result on exchange.
    @StreamBean
    public Supplier<MessageA> send() {
        return () -> MessageA.builder().msg("foo").build();
    }
    
    /* 
    quarkus.rabbitmq.bindings.send-out.destination=sender
    quarkus.rabbitmq.bindings.send-out.content-type=application/json

    quarkus.rabbitmq.bindings.process-in.destination=sender
    quarkus.rabbitmq.bindings.process-in.content-type=application/json
    quarkus.rabbitmq.bindings.process-in.group=in-group-1
    quarkus.rabbitmq.bindings.process-in.dlq=true
    quarkus.rabbitmq.bindings.process-out.destination=processed
    quarkus.rabbitmq.bindings.process-out.content-type=application/json

    quarkus.rabbitmq.bindings.receive-in.destination=processed
    quarkus.rabbitmq.bindings.receive-in.content-type=application/json
    quarkus.rabbitmq.bindings.receive-in.group=in-group-2
    quarkus.rabbitmq.bindings.receive-in.dlq=true
     */
}

I like the fact the link between RabbitMQ and code for the developer is just a standard functional interface from core Java.

Can we organise a chat to discuss ideas, plans and viability of these projects compared to "SmallRye Reactive Messaging - RabbitMQ"?

[kdubb]

I'm certainly up for a chat.

My immediate thoughts were to update the Vert.x client to use channels; it also has other moderately serious issues that have been worked around in the SM-RM connector. For our purposes a channelized Vert.x client would solve our one exceptional service case.

For me, the SM-RM model is simple & easy and we're pretty happy with it in the general sense.

[bpasson]

What would be a suitable time. For me best times would be 20 - 22 UTC. What do you prefer?

[bpasson]

@kdubb Any update on what you want?