On Tue, Sep 20, 2011 at 11:04 AM, Rajith Attapattu <[email protected]> wrote: > 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)
Sorry I misunderstood here. I thought you were referring to the JMS spec. I agree that as per the AMQP spec it's not correct. > 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]
