Store the Plain Text Group Id instead or in addition to a UUID [INT-2675]

Gunnar Hillert opened INT-2675 and commented

When operating on the JDBCMessageStore lookups are made by providing the groupId, which calls getKey(Object input) which then calls

UUIDConverter.getUUID(input).toString()

The PointToPointChannelParser parses the MessageStore attribute (message-store) and initializes a MessageGroupQueue. When we initialize the MessageGroupQueue we provid the groupId via its contructor. The groupId is the concatenation of the string representation of the message-store attribute + ":" + channel name.

In the JDBC Message Store, we convert the group id from e.g. "jdbcMessageStore:inputChannel" to an UUID.

As users may need to investigate the tables, this may be cumbersome and s(he) may not have a clue what group key refers to the UUID value in the table.

A side question is how portable (between JVMs) is :

UUID.nameUUIDFromBytes(("jdbcMessageStore:inputChannel").getBytes("UTF-8"))  

Ideally, we should probably store the clear text groupId in the tables, considering:

• this must not impact efficiency
• avoid table locking in concurrent access situations

Affects: 2.1.3

This issue is a sub-task of #6647

Issue Links:

• #6735 Optimize AbstractCorrelatingMessageHandler Lock Keys

• #6726 JDBC Message Store - Reaper Can Reap Released Group of Messages

Start with JDBCMessageStore.getKey(Object), then trace how PointToPointChannelParser initializes MessageGroupQueue and supplies its groupId. Confirm how the JDBC tables currently represent the UUID and how related locking paths behave. Done means the plain-text groupId is available for table investigation without harming efficiency or concurrent access.