activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Ländle (JIRA) <jira+amq...@apache.org>
Subject [jira] Issue Comment Edited: (AMQNET-245) Stomp.MessageProducer doesn't set the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Date Fri, 21 May 2010 13:13:51 GMT

    [ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59474#action_59474
] 

Andreas Ländle edited comment on AMQNET-245 at 5/21/10 9:12 AM:
----------------------------------------------------------------

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).

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);
          }

I reported this as a bug: https://issues.apache.org/activemq/browse/AMQNET-253

      was (Author: alsoloplan):
    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).

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);
          }
  
> Stomp.MessageProducer doesn't set the TimeStamp to zero (unix epoc) if DisableMessageTimestamp
is true.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AMQNET-245
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-245
>             Project: ActiveMQ .Net
>          Issue Type: Improvement
>          Components: Stomp
>         Environment: Win7, VS2008, .netcf-2.0
>            Reporter: Andreas Ländle
>            Assignee: Timothy Bish
>            Priority: Trivial
>             Fix For: 1.3.0
>
>         Attachments: MessageProducer.patch
>
>
> If I interpret the comment on Apache.NMS.IMessage.NMSTimestamp correctly, the timestamp
of a message of send by a message producer with disabled timstamping should reflect the unix
epoc. This is also what the JMS specification says in section 3.4.4 (JMSTimestamp).
> But since the TimeStamp property of a message is set to DateTime.UtcNow in Apache.NMS.Stomp.Commands.Message.ctor()
and the Apache.NMS.Stomp.MessageProducer.Send(...) implementation only updates the message
timestamp (if message timestampng isn't disabled for the producer), the timestamp of a message
send via STOMP can never be "zero" (=unix epoc).
> Maybe a simple solution might be to add an else-branch to the MessageProducer-Send-implementation
(see attached patch file), but i don't know if this follows the NMS-projects design intentions.

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


Mime
View raw message