[
https://issues.apache.org/jira/browse/ARTEMIS-4657?focusedWorklogId=907539&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-907539
]
ASF GitHub Bot logged work on ARTEMIS-4657:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 29/Feb/24 09:47
Start Date: 29/Feb/24 09:47
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #4833:
URL:
https://github.com/apache/activemq-artemis/pull/4833#issuecomment-1970769791
Sacrificing any of the existing widely-used working String-based correlation
ID interop in favour of the non-portable little-used byte[] versions, that dont
work currently, simply does not strike me as an improvement whatsoever.
String based JMSCorrelationID is the _primary, required_ form of
JMSCorrelationID. Its what JMS providers _must_ implement. Its the only way to
correlate using the String-only JMSMessageID values. Its what people use in
selectors. Its what applications just tend to use in general (I dont think I
have ever come across a real world application that used the byte[], whereas I
know I have come across lots that use the String).
Its also what frameworks tend to use, because they simply cant depend on the
byte[] method and thus avoid it. The Camel repo for example is littered with
String-based setJMSCorrelationID usage, but doesnt seem to have a single
setJMSCorrelationIDAsBytes usage (according to a couple searches of their git
repo). Ditto for Spring.
The byte[] method is optional, you do not need to implement it at all and
are simply allowed to throw UnsupportedOperationException. The API expressly
notes that it is non-portable to discourage its use. The TCK only has 1 test
variant (only only added with JMS 2) that uses it, and it simply swallows that
potential UOE and prints it is ignoring it. The method is essentially only
there to support niche cases of providers that also have non-JMS clients that
require a specific 'native' correlation encoding. I think I historically saw it
referenced for interop with the 'non-jms' IBM MQ clients for example, as they
encoded things in a certain structure with certain hex encodings etc that need
to be matched.
Issue Time Tracking
-------------------
Worklog Id: (was: 907539)
Time Spent: 1h 10m (was: 1h)
> Support correlation ID compatibility between JMS clients
> --------------------------------------------------------
>
> Key: ARTEMIS-4657
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4657
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Justin Bertram
> Assignee: Justin Bertram
> Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently there are some use-cases with both {{String}} and {{byte[]}} values
> of JMS correlation ID that don't work between Core, OpenWire, and AMQP. We
> should support as many as possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
