You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Andreas Ländle (JIRA)" <ji...@apache.org> on 2010/03/17 11:21:45 UTC
[jira] Created: (AMQNET-245) Stomp.MessageProducer doesn't set the
TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
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: Jim Gomes
Priority: Trivial
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.
[jira] Commented: (AMQNET-245) Stomp.MessageProducer doesn't set
the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58287#action_58287 ]
Timothy Bish commented on AMQNET-245:
-------------------------------------
Just double checked and the broker will set the "timestamp" field so adding that should be fine. You'd need to add in the read of the TimeStamp header in the StompWireFormat as well I'd think.
Can you work up a complete patch with the changes needed and include a Unit Test to validate that the functionality is working as expected. That would help us out a lot since I won't have time to get to that this week.
> 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.
[jira] Updated: (AMQNET-245) Stomp.MessageProducer doesn't set the
TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish updated AMQNET-245:
--------------------------------
Fix Version/s: 1.3.0
> 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.
[jira] Commented: (AMQNET-245) Stomp.MessageProducer doesn't set
the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (AMQNET-245) Stomp.MessageProducer doesn't set the
TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish resolved AMQNET-245.
---------------------------------
Resolution: Fixed
I've added a patch to set the timestamp in the stomp frame and not to initialize the timestamp in the message, this should now work like the API docs indicate. If you test it out and its still not working as you'd expect please reopen the issue.
> 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.
[jira] Updated: (AMQNET-245) Stomp.MessageProducer doesn't set the
TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Andreas Ländle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Ländle updated AMQNET-245:
----------------------------------
Attachment: MessageProducer.patch
> 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: Jim Gomes
> 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.
[jira] Assigned: (AMQNET-245) Stomp.MessageProducer doesn't set the
TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish reassigned AMQNET-245:
-----------------------------------
Assignee: Timothy Bish (was: Jim Gomes)
> 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.
[jira] Commented: (AMQNET-245) Stomp.MessageProducer doesn't set
the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Andreas Ländle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58285#action_58285 ]
Andreas Ländle commented on AMQNET-245:
---------------------------------------
Maybe another issue: The StompWireFormat never writes the timestamp to the outgoing 'send'-frame (nonetheless the timestamp is recognized for incoming messages).
Would you add something like:
if(command.Timestamp != 0)
{
frame.SetProperty("timestamp", command.Timestamp);
}
to StompWireFormat.WriteMessage(Message command, BinaryWriter dataOut) ?
> 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.
[jira] Commented: (AMQNET-245) Stomp.MessageProducer doesn't set
the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Andreas Ländle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59474#action_59474 ]
Andreas Ländle commented on AMQNET-245:
---------------------------------------
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.
[jira] Commented: (AMQNET-245) Stomp.MessageProducer doesn't set
the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is true.
Posted by "Andreas Ländle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58451#action_58451 ]
Andreas Ländle commented on AMQNET-245:
---------------------------------------
Hi Timothy, if I find time i will try to develop a patch - unfortunately (or fortunately) this issue isn't critical for us and i have lot of other things to get rid of. So I couldn't promise you a patch over a specific time period.
> 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.
[jira] Issue Comment Edited: (AMQNET-245) Stomp.MessageProducer
doesn't set the TimeStamp to zero (unix epoc) if DisableMessageTimestamp is
true.
Posted by "Andreas Ländle (JIRA)" <ji...@apache.org>.
[ 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.