We are attempting to use the amqp basic property "timestamp" via the
RabbitMQ java client (see code below) to record the point in time when
the message gets sent. However, we are finding that when a message is
pulled from the bus, the timestamp property of the retrieve message
has had its milliseconds component dropped. We are using rabbitmq
2.7.1 with erlang R15B. Is this a bug or by design? Other than using
our own headers, is there a better way to do this? We would love it
if Rabbit itself would provide this timestamp as it would eliminate
issues with client clocks not being in sync.

BasicProperties props = new BasicProperties.Builder()
.messageId(UUID.randomUUID().toString())
.correlationId(UUID.randomUUID().toString())
.type("test.event")
.replyTo("replyto_routingkey")
.timestamp(new Date(2930830427321L))
.headers(headers)
.build();

Thereafter do a basicPublish and basicGet() and compare sent and
received timestamps. They differ by 321 mills.

Search Discussions

  • Marek Majkowski at Feb 23, 2012 at 11:12 am

    On Wed, Feb 22, 2012 at 20:04, Ken Baltrinic wrote:
    We are attempting to use the amqp basic property "timestamp" via the
    RabbitMQ java client (see code below) to record the point in time when
    the message gets sent. ?However, we are finding that when a message is
    pulled from the bus, the timestamp property of the retrieve message
    has had its milliseconds component dropped. ?We are using rabbitmq
    2.7.1 with erlang R15B. ?Is this a bug or by design? Other than using
    our own headers, is there a better way to do this? ?We would love it
    if Rabbit itself would provide this timestamp as it would eliminate
    issues with client clocks not being in sync.
    AMQP spec says:
    4.2.5.4 Timestamps
    Time stamps are held in the 64-bit POSIX time_t format with an
    accuracy of one second. By using 64 bits we avoid future wraparound
    issues associated with 31-bit and 32-bit time_t values.
    So, as far as you're using the built-in timestamp field, it will be
    rounded to a second. Sorry.

    Marek
  • Marek Majkowski at Feb 23, 2012 at 11:15 am

    On Thu, Feb 23, 2012 at 11:12, Marek Majkowski wrote:
    On Wed, Feb 22, 2012 at 20:04, Ken Baltrinic
    wrote:
    We are attempting to use the amqp basic property "timestamp" via the
    RabbitMQ java client (see code below) to record the point in time when
    the message gets sent. ?However, we are finding that when a message is
    pulled from the bus, the timestamp property of the retrieve message
    has had its milliseconds component dropped. ?We are using rabbitmq
    2.7.1 with erlang R15B. ?Is this a bug or by design? Other than using
    our own headers, is there a better way to do this? ?We would love it
    if Rabbit itself would provide this timestamp as it would eliminate
    issues with client clocks not being in sync.
    AMQP spec says:
    4.2.5.4 Timestamps
    Time stamps are held in the 64-bit POSIX time_t format with an
    accuracy of one second. By using 64 bits we avoid future wraparound
    issues associated with 31-bit and 32-bit time_t values.
    So, as far as you're using the built-in timestamp field, it will be
    rounded to a second. Sorry.
    Of course nothing is topping you from sending a custom header
    with an arbitrary data type (float, string or long long). That way
    you could send the timestamp data in any format you wish.

    Marek

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 22, '12 at 8:04p
activeFeb 23, '12 at 11:15a
posts3
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Marek Majkowski: 2 posts Ken Baltrinic: 1 post

People

Translate

site design / logo © 2022 Grokbase