rebus-org / Rebus

:bus: Simple and lean service bus implementation for .NET
https://mookid.dk/category/rebus
Other
2.26k stars 355 forks source link

cooperate with other team problem #397

Closed houwenlong789 closed 8 years ago

houwenlong789 commented 8 years ago

I am in a team that cooperate with other teams. We transfer messages use rabbitmq. But my team use rebus, other team may use java or c++ rabbitmq client directly. The problem is that rebus require message header must have message Id. If not, received message can not be handled. So I overwride SimpleRetryStrategyStep and give message header a Id. if it can cause other problem?

mookid8000 commented 8 years ago

In scenarios like this, I usually recommend people to write a bridge that goes through receiving messages in their custom format and then re-publish them using Rebus.

This makes the boundary between your systems clear and reduces the risk that potentially slightly malformed messages have unintended consequences somewhere further down the line.

With that said: I cannot readily think of any problems that can be caused by this if it looks like it works to you, provided that the ID is a real message ID. If a redelivered message could arrive with a different ID, you destroy Rebus' ability to track the message between retries.

dariogriffo commented 4 years ago

Bringing this back alive, sorry, we are working with a nodejs integration, ideally we don't to use the bridge, because that means handling everything that Rebus already does: retries, reconnection, etc, etc. Our idea is to look at all the rbs-* headers and setting them with a little bit of common sense. Any advice (besides a "build a bridge" :) Thanks a lot!

mookid8000 commented 4 years ago

Our idea is to look at all the rbs-* headers and setting them with a little bit of common sense (...)

That's totally doable. 🙂

Any advice?

Apply common sense. But since you are already doing that, I don't think I have anything to add. 😉