[
https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58286#action_58286
]
Timothy Bish commented on AMQNET-245:
-------------------------------------
The time stamp field isn't really all that meaningful in a Stomp Message since
there is no STOMP timestamp message property, only expires. So you are really
better off checking if the Message has an expiration time set.
Also note that Stomp does not guarantee any compliance with the JMS spec.
> 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
> 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.
