activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Ländle (JIRA) <>
Subject [jira] Commented: (AMQNET-253) STOMP: Expiration date of message are corrupt if the producer 'timestamping' is disabled
Date Fri, 21 May 2010 14:13:53 GMT


Andreas Ländle commented on AMQNET-253:

Hi Timothy,
sorry for being unclear - the bug was introduced with the fix for AMQNET-245 - let me explain...

a) The producer only set's the timestamp if it's DisableMessageTimestamp property is false
b) The expiration date of a message is calculated ( ExpirationDate = TimeStamp + TimeToLive)

So since the fix for AMQNET-245 the TimeStamp isn't initialized in the constructor of the
Message class (trunk: SVN# 929131 - Message.cs)

So imagine - the timestamp of the message is never set (value is 0), but i set the TimeToLive
property of the message!
The message gets send and it's expiration date is calculated - which means ExpirationDate
= 0 + TimeToLive.

Indeed the problem only occurs in a very rare case - i didn't want to transmit the timestamp
but i want to transfer an expiration date (it's important to us to reduce data volume).

Hope things got clearer now - if not please let me know and i will try to find a even better

> STOMP: Expiration date of message are corrupt if the producer 'timestamping' is disabled
> ----------------------------------------------------------------------------------------
>                 Key: AMQNET-253
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: NMS
>    Affects Versions: 1.2.0
>            Reporter: Andreas Ländle
>            Assignee: Jim Gomes
>            Priority: Minor
> Please Note: Since NMS has dependencies between the NMSTimestamp and NMSTimeToLive properties
- Disabling the timestamps on the producer results in corrupted expiration dates of the messages!
> Reproduction:
> Set the TTL of a message to 1 hour - send this message via a producer which has DisableMessageTimestamp=true.
> Now take a look at the "expires" field of the transfered message - it's value is all
to small (and so the broker would discard the message immediately).
> (previous to the fix for the TimeStamp
of a message was set during construction - so the interconnection of Timestamp and TTL wasn't
so obvious)
> Workaround:
> I have worked around this issue with a dirty hack - i just bypass the TTL-Timespan.
> var stompMessage = nmsMessage as BaseMessage;
> if (stompMessage != null)
> { stompMessage.Expiration = DateUtils.ToJavaTimeUtc(myExpirationDate); } 
> Please let me know if i was unclear or if you need more information.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message