correlation_id versus correlationId in tutorials

[Mark Kimball]

Hi all,

I'm finding inconsistencies in implementations of the rpc tutorial and I'm wondering if I'm way off base. 

When I use spring AMQP in Java, it sets the correlationId property (I believe they've taken it a step further and have now deprecated correlationId in favor of using correlationIdString).

I'm also using the node library "rabbot" as the client on this rpc model. Rabbot seems inconsistent in its approach. It sets the messageId property on the client and then copies messageId to the correlationId property in its return.

When I look at the tutorials, Java and C# use the correlationId property and all the rest use the correlation_id property. The diagrams in all the tutorials are consistently using the correlation_id property.

I understand there is no standard protocol, but this correlation id is finding its way into widely used libraries and seems to be evolving into a standard, albeit an inconsistent one.

I haven't been able to find any discussion on this and I've already wasted a fair amount of time with these library inconsistencies. This only seems to pop up when we're using different platforms on an rpc conversation. To me, this seems inconsistent with a primary use case for an MQ (an agnostic message-passer).

Does this seem like something that requires further discussion and clarification or am I just missing the boat on this whole thing?

If this has been discussed, if someone would be so kind as to point me in the right direction, I'd be very grateful.

Mark

[Gary Russell]

Spring AMQP maps its correlationId (and correlationIdString) to/from the standard correlation_id property. spring-messaging is multi-protocol so we standardized to correlationId at the API level.

The deprecation you are seeing is because we've switched from byte[] to String (in 2.0 setCorrelationId will be a String).

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Kimball]

Hi Gary,

Thanks for the reply. I'll admit my strength isn't on the spring side. That application was provided by another org and it hasn't behaved as you explain (it must override the properties somewhere). I'm sure it has to do with a misunderstanding of the use of spring integration and rabbitmq. I'll go try to unravel that mystery. I apologize for my misunderstanding. The work you guys do is nothing short of amazing.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

[Gary Russell]

Mark,

My apologies - I have been doing a lot of work with content_id lately and I had that on my mind.

It's mapped to the correlation id property in the amqp properties within the protocol itself. The "name" of that property at the application layer depends on the API implementation.

When using Spring Integration on top of Spring AMQP, it's mapped to a header `amqp_correlationId`.

Sorry for the confusion.

Gary

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.