Gordon,
Many thanks.
Yes, other parts of our system are probably using the JMS client, and
that's where I suspect my millisecond numbers are coming from.
I think I'll go with my work-around, if if, in the year 1 or so someone
is unhappy, they'll just have to dig me up.
Bill
On Tue, Apr 1,
On 04/01/2014 10:03 PM, Bill Freeman wrote:
I'm receiving messages using the python qpid.messaging API, and getting a
value for x-amqp-0-10.timestamp that is an instance of
qpid.datatypes.timestamp, and whose value, when coerced to a str (print) or
to a float, is apparently miliseconds since the
I'm receiving messages using the python qpid.messaging API, and getting a
value for x-amqp-0-10.timestamp that is an instance of
qpid.datatypes.timestamp, and whose value, when coerced to a str (print) or
to a float, is apparently miliseconds since the Unix epoch.
Yet looking at the implementation
Hi all,
I have been using qpid for more than a year now and never experienced any
connection problems before. However, currently we have some network issues in
our company and one of the effects is that qpid is constantly reporting errors
with sync. This is happening in test environment, but it
Thanks very much Gordon. I have had some previous endeavours with the
dispatch router (in fact I started there before switching to the broker)
and will return to that plan of attack.
I think we will still need brokers in this topology in order to queue
messages for offline clients, otherwise the r