SmallRye RabbitMQ support in Quarkus about quarkus-rabbitmq-client

[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?