search

Particular / NServiceBus

Build, version, and monitor better microservices with the most powerful service platform for .NET
https://particular.net/nservicebus/
Other
2.07k stars 648 forks source link

Support receiving messages without a message id for integration scenarios #2521

Closed andreasohlund closed 9 years ago

andreasohlund commented 9 years ago

At the moment we require the transports to make sure each received message has a message id. We've seen a few (rabbitmq) customers asking for this limit to be removed.

In order to support this we would need to generate a stable id , for FLR to work correctly.

My idea is to generate a deterministic guid based on the headers + body.

Other ideas?

johnsimons commented 9 years ago

If we supporting interop, what are the required headers for the message to be correctly processed?

Regarding generating a deterministic guid, I don't think we can do this, the message body + headers could be exactly the same which seems to be reasonable. So I can't see how we can avoid the sender assigning a unique id to the message.

johnsimons commented 9 years ago

Unless the transport itself can provide us with a stable unique id per message ?

andreasohlund commented 9 years ago

This seems to suggest that correlation id is always present for rabbit:

http://stackoverflow.com/a/11461872/236004

So you're onto something @johnsimons

On Fri, Oct 24, 2014 at 12:53 AM, John Simons notifications@github.com wrote:

Unless the transport itself can provide us with a stable unique id per message ?

— Reply to this email directly or view it on GitHub https://github.com/Particular/NServiceBus/issues/2521#issuecomment-60321825 .

andreasohlund commented 9 years ago

We should require all transports to give us an id. Rabbit has already been modified to allow the id strategy to be pluggable. Closing this