Multiple RoutingKeys per Queue not supported? java.lang.IllegalStateException: Duplicate key about springwolf-core HOT 4 CLOSED

Thanks for the detailed issue, I will take a look

from springwolf-core.

I see the problem, just want to ask about the expected results:

1. For a given channel (same exchange and queue), when given multiple bindings each with a different routing key, the operation binding field cc will be a list containing all the routing keys associated with that exchange and queue.
2. Given the same queue name on different exchanges, like in your example, each will have its own channel. Currently the channel name is the queue name, but that will have to change to "exchange-name/queue-name". The operation binding in this case will contain only the routing key associated with that specific channel.

Does that make sense? Please let me know if you have any thoughts, and if you'd like to talk about this further you can join the discord server https://discord.gg/HZYqd5RPTd

from springwolf-core.

Hio, sorry for not getting back to you sooner. Thanks for looking into my issue.

Mhh I see it is not easy to represent AMQP/RabbitMQ with AsyncApi, since you are very free how to use it.

So if I understand the AsyncApi-Specs correctly, a channel is something that can receive or send messages.
So for me in the AMQP/RabbitMQ world, that would be a queue or a routingKey (or exchange/queue (or exchange/queue/routingkey)). (https://github.com/asyncapi/bindings/blob/master/amqp/README.md#channel)

For me personally and how I use rabbitmq the channel is just the routingKey. The other stuff is just "bindings".

For Events the routinkKey is the event and multiple services/queues listen on it.
For Commands the routingKey is the endpoint of a single service/single queue that processes it.
The exchange doesnt really matter to me at all, since in the end they all are bound to three "main"-exchanges.

So ideally, in my case I would get two channels (one per routingKey) with a bunch of bindings. But not sure if thats within the realm of possibility in the current spec.

But I am also fine with your suggestions, if my approach would break to many other ppls docs.

from springwolf-core.

We have low usage for amqp plugin, so we will not be able to invest time in this. If someone would like to try contributing an implementation, please let us know. Closing for now.

from springwolf-core.