Minor Description
When an AMQP message is expired, it is moved to the ExpiryQueue. With this process, a few extra properties are added to describe the original/previous location of the message.
However, property extraProperties._AMQ_ACTUAL_EXPIRY is added as a string value. This could have been an integer value to match the original data type.
Since JS function formatTimestamp() is used to represent the value, the original string value is displayed again in parentheses.
Solution is expected to be one of these 3:
1) (preferred) _AMQ_ACTUAL_EXPIRY is made numeric. Function formatTimestamp() can do its work and a proper date-time will be shown.
2) (alternative) _AMQ_ACTUAL_EXPIRY remains a string. Function formatTimestamp() should no longer be called.
3) (alternative) _AMQ_ACTUAL_EXPIRY remains a string. Function formatTimestamp() is called with the parseInt() value of the string when the string consists only of digits.
I'll create a PR for solution 1.
Analysis notes:
- (OK) example org.apache.activemq.artemis.jms.example.ExpiryExample uses getLongProperty("_AMQ_ACTUAL_EXPIRY"); and
- (OK) org.apache.activemq.artemis.core.server.impl.QueueImpl uses copy.setBrokerProperty(Message.HDR_ACTUAL_EXPIRY_TIME, System.currentTimeMillis());; and
- (OK) org.apache.activemq.artemis.core.server.transformer.ServerMessageImpl uses long actualExpiryTime = System.currentTimeMillis(); message.putLongProperty(Message.HDR_ACTUAL_EXPIRY_TIME, actualExpiryTime);; and
- (OK) org.apache.activemq.artemis.tests.integration.client.ExpiryAddressTest uses Long actualExpiryTime = (Long) tm.getObjectProperty(Message.HDR_ACTUAL_EXPIRY_TIME);.
- ...
- (!!!) org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.toPropertyMap() converts all extraProperties to strings (and truncate them when they are too long).
Development notes:
Add condition on value type. Numeric values are copied as-is. All other types keep their old behaviour.
Test result:
Attachments
Attachments
Issue Links
- links to
