Bug 751883

Can other clients (JMS and python) see the timestamp?

I have not verified this using a JMS client.

I have used it with the python client.  In fact, the upstream repo contains a unit test for this feature.  See:

qpid/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/management.py 

from that test, the timestamp is extracted from the delivery_properties field:


+        msg = incoming.get(timeout=1)
+        self.assertEqual("abc", msg.body)
+        self.assertEqual(msg.has("delivery_properties"), True)
+        dp = msg.get("delivery_properties")
+        assert(dp.timestamp)

There is also a C++ client based check in:


qpid/trunk/qpid/cpp/src/tests/BrokerOptions.cpp 


        Receiver receiver = fix.session.createReceiver("test-q");
 	messaging::Message in;
 	BOOST_CHECK(receiver.fetch(in, Duration::IMMEDIATE));
 	Variant::Map props = in.getProperties();
 	BOOST_CHECK(props.find("x-amqp-0-10.timestamp") != props.end());
 	BOOST_CHECK(props["x-amqp-0-10.timestamp"]); 


Gordon, would these be sufficient for the user documentation?  Also, are you aware of any JMS-based tests that access a messages' 0.10 delivery properties that I can add timestamp tests to?  Thx.

(In reply to comment #2)
> I have not verified this using a JMS client.
> 
> I have used it with the python client.  In fact, the upstream repo contains a
> unit test for this feature.  See:
> 
> qpid/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/management.py 
> 
> from that test, the timestamp is extracted from the delivery_properties field:
> 
> 
> +        msg = incoming.get(timeout=1)
> +        self.assertEqual("abc", msg.body)
> +        self.assertEqual(msg.has("delivery_properties"), True)
> +        dp = msg.get("delivery_properties")
> +        assert(dp.timestamp)

Thats the old API though, which we no longer encourage people to use. We really need to access it via the messaging API  in the same way as for c++.

> There is also a C++ client based check in:
> 
> 
> qpid/trunk/qpid/cpp/src/tests/BrokerOptions.cpp 
> 
> 
>         Receiver receiver = fix.session.createReceiver("test-q");
>   messaging::Message in;
>   BOOST_CHECK(receiver.fetch(in, Duration::IMMEDIATE));
>   Variant::Map props = in.getProperties();
>   BOOST_CHECK(props.find("x-amqp-0-10.timestamp") != props.end());
>   BOOST_CHECK(props["x-amqp-0-10.timestamp"]); 
> 
> 
> Gordon, would these be sufficient for the user documentation?

Yes, I think we just need to add a line or two to the end of section 2.16 of the programmers guide (http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s16.html) alongside x-amqp-0-10.routing-key. (But we need to highlight if this is not yet supported in python).

>  Also, are you
> aware of any JMS-based tests that access a messages' 0.10 delivery properties
> that I can add timestamp tests to?  Thx.

See testQpidExtensionProperties() in http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/message/JMSPropertiesTest.java?view=markup&pathrev=1153274.

Might also want to update table 3.4 of the programming guide.

Good find Gordon - I dropped the ball on the python and java client side.

I've got python client support ready to go upstream, just asked Rafi to review the patch:

https://issues.apache.org/jira/browse/QPID-3626


Java is going to be a bit more problematic - the java client currently uses the AMQP 0-10 timestamp delivery property to hold the JMSTimestamp.  We'll need more work there for a correct fix.  See:

https://issues.apache.org/jira/browse/QPID-3628
https://issues.apache.org/jira/browse/QPID-3627

Not sure if client-side support is a release blocker - a point to consider: this timestamp feature was meant to be used as a way to debug potential msg group problems (specifically, to determine if a group has been enqueued "too long" - for whatever reason).  As such, the user would be interested in getting timestamps of enqueued messages, not delivered messages (and msg groups has a qmf method call to do exactly that).

(In reply to comment #4)
> Good find Gordon - I dropped the ball on the python and java client side.
> 
> I've got python client support ready to go upstream, just asked Rafi to review
> the patch:
> 
> https://issues.apache.org/jira/browse/QPID-3626
> 
> 
> Java is going to be a bit more problematic - the java client currently uses the
> AMQP 0-10 timestamp delivery property to hold the JMSTimestamp.  We'll need
> more work there for a correct fix.  See:
> 
> https://issues.apache.org/jira/browse/QPID-3628
> https://issues.apache.org/jira/browse/QPID-3627
> 
> Not sure if client-side support is a release blocker - a point to consider:
> this timestamp feature was meant to be used as a way to debug potential msg
> group problems (specifically, to determine if a group has been enqueued "too
> long" - for whatever reason).  As such, the user would be interested in getting
> timestamps of enqueued messages, not delivered messages (and msg groups has a
> qmf method call to do exactly that).

I don't think it is a release blocker, but it would be nice to get the fix in for the python client just for consistency (since it is small and hopefully uncontroversial).

Fixed upstream at http://svn.apache.org/viewvc?view=rev&rev=1203313

Tested on RHEL 5.7 and 6.2 (architectures i386 and x86_64).

Packages used for testing:

RHEL6.2
python-qpid-0.14-2.el6
python-qpid-qmf-0.14-3.el6
qpid-cpp-client-0.14-1.el6
qpid-cpp-client-devel-0.14-1.el6
qpid-cpp-client-devel-docs-0.14-1.el6
qpid-cpp-client-rdma-0.14-1.el6
qpid-cpp-client-ssl-0.14-1.el6
qpid-cpp-debuginfo-0.14-1.el6
qpid-cpp-server-0.14-1.el6
qpid-cpp-server-cluster-0.14-1.el6
qpid-cpp-server-devel-0.14-1.el6
qpid-cpp-server-rdma-0.14-1.el6
qpid-cpp-server-ssl-0.14-1.el6
qpid-cpp-server-store-0.14-1.el6
qpid-cpp-server-xml-0.14-1.el6
qpid-java-client-0.14-1.el6
qpid-java-common-0.14-1.el6
qpid-java-example-0.14-1.el6
qpid-qmf-0.14-3.el6
qpid-qmf-debuginfo-0.14-3.el6
qpid-qmf-devel-0.14-3.el6
qpid-tests-0.14-1.el6
qpid-tools-0.14-1.el6

RHEL5.7
python-qpid-0.14-1.el5
python-qpid-qmf-0.14-2.el5
qpid-cpp-client-0.14-4.el5
qpid-cpp-client-devel-0.14-4.el5
qpid-cpp-client-devel-docs-0.14-4.el5
qpid-cpp-client-rdma-0.14-4.el5
qpid-cpp-client-ssl-0.14-4.el5
qpid-cpp-mrg-debuginfo-0.14-4.el5
qpid-cpp-server-0.14-4.el5
qpid-cpp-server-cluster-0.14-4.el5
qpid-cpp-server-devel-0.14-4.el5
qpid-cpp-server-rdma-0.14-4.el5
qpid-cpp-server-ssl-0.14-4.el5
qpid-cpp-server-store-0.14-4.el5
qpid-cpp-server-xml-0.14-4.el5
qpid-java-client-0.10-9.el5
qpid-java-common-0.10-9.el5
qpid-java-example-0.10-9.el5
qpid-qmf-0.14-2.el5
qpid-qmf-debuginfo-0.14-2.el5
qpid-qmf-devel-0.14-2.el5
qpid-tests-0.14-1.el5
qpid-tools-0.14-1.el5


-> VERIFIED

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This new feature causes the broker to insert a timestamp (using 64bit POSIX time_t format as described in AMQP 0-10) into the header of every message received by the broker.

This timestamp represents the moment the message arrives at the broker.  It may be used as a debug aid to determine how long a message is held by the broker.

This feature may be enabled on the command line when invoking the broker  by specifying the "--enable-timestamp=yes" option. Example:

qpidd -d --auth no --enable-timestamp=yes

This feature may also be turned on and off dynamically via the QMF Broker method "setTimestampConfig".  It's current value (on or off) may be retrieved via the QMF Broker method "getTimestampConfig".

By default this feature is disabled.  Enabling this feature may introduce latency, as each message is modified by the broker.