On Wed, Sep 14, 2011 at 12:46 PM, Jiri Krutil <[email protected]> wrote: > Hi > > I'm having problems with timestamps when sending messages from a C++ client > and receiving them in a Java client. > The C++ messaging client v0.7 does not allow to set the message timestamp. > It allows to set TTL, but I'm not doing that. > According to the specs, the message timestamp is assigned by the broker -- > this does not seem to happen. > When receiving the message in the Java client, the message headers are as > follows: > > JMS Correlation ID: > JMS timestamp: 0 > JMS expiration: 0 > JMS priority: 4 > JMS delivery mode: 2 > JMS reply to: null > JMS Redelivered: false > JMS Destination: direct://foo//?routingkey='' > JMS Type: null > JMS MessageID: null > JMS Content-Type: application/octet-stream > > If I do set TTL in the C++ client, the Java client receives JMS expiration > of 1316002516. This seems to be seconds-since-epoch, but the JMS specs says > the timestamps should be in millis-since-epoch. > This seems to be related to https://issues.apache.org/jira/browse/QPID-1551. > > My questions are: > - Why does the broker not set the message timestamp? (I thought the spec > says it should)
I don't think this is correct. The JMS 1.1 specification section 3.4.4 states that, "When a message is sent, JMSTimestamp is ignored. When the send method returns, the field contains a a time value somewhere in the interval between the call and the return. It is in the format of a normal Java millis time value." In other words when the send method returns and you invoke getJMSTimestamp() on the message you just sent, it should contain the timestamp. Therefore the current behaviour doesn't seem wrong. If the timestamp is to be set by the broker then we cannot do the above. It also state the following, which seems to sort of contradict the above - especially in the case of transactions. "It is not the time the message was actually transmitted because the actual send may occur later due to transactions or other client side queueing of messages." So you could argue that the broker is supposed to set it. But if it does then it is at odds with the above paragraph. > - Why does the Java client set the timestamp fields to zero instead of null, > if they are not set in the AMQP message? In the same section (3.4.4) the spec states "When a client sets a producer to disable timestamps it is saying that it does not depend on the value of timestamp for the messages it produces. If the JMS provider accepts this hint, these messages must have the timestamp set to zero;" Therefore the current behaviour is correct. > - Why does not the Java client translate from seconds-since-epoch to > millis-since-epoch? Again from the spec (section 3.4.4) - " It is in the format of a normal Java millis time value." Besides in Java time is specified in millis since epoch and not seconds. > - Is any of these fixed in the latest version of the broker or Java client? I don't think the issues raised above are bugs. If you have any further questions, please feel free to ask. Regards, Rajith > Cheers > Jiri > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
