An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120207/03177055/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remote-site.png
Type: image/png
Size: 71581 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120207/03177055/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local-site.png
Type: image/png
Size: 62325 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120207/03177055/attachment-0001.png>

Search Discussions

  • Emile Joubert at Feb 7, 2012 at 3:37 pm
    Hi,
    On 07/02/12 03:48, Mihir Mone wrote:
    The really baffling fact is that only configuration 1 has this issue,
    configuration 2 works fine. The only difference is a different OS at the
    remote end of things in configuration 2.
    Can you reproduce this problem with a smaller message, or without using
    shovel?

    Does it also happen when you receive the message with any other AMQP
    client, or with the "rabbitmqadmin get" command?

    Have you confirmed that the original message sent to the broker does not
    already contain the defect?


    -Emile
  • Mihir Mone at Feb 7, 2012 at 10:35 pm
    Hi Emile,

    No this problem does not occur if the message is small. The payload is
    basically database table rows that are being synched between two sites.
    When the number of rows per payload is under 10 this error does not
    occur. But once it starts getting past 15 or so I am seeing this error.
    The configuration 1 which has this error is configured for 500 rows,
    which configuration 2 is configured for 3000 rows. And configuration 2
    works fine !!

    Yes the error is present even when you receive a message through
    "rabbitmqadmin get" command.

    Yes, I have confirmed that the original message sent to the broker at
    the remote end is OK. If you see the screenshots I have sent in the
    original email, one of them is named remote-site and the other is named
    local-site. They are nothing but dumps taken from the
    rabbitmq_management web UI.

    - Mihir
    On 8/02/2012 2:37 AM, Emile Joubert wrote:
    Hi,
    On 07/02/12 03:48, Mihir Mone wrote:
    The really baffling fact is that only configuration 1 has this issue,
    configuration 2 works fine. The only difference is a different OS at the
    remote end of things in configuration 2.
    Can you reproduce this problem with a smaller message, or without using
    shovel?

    Does it also happen when you receive the message with any other AMQP
    client, or with the "rabbitmqadmin get" command?

    Have you confirmed that the original message sent to the broker does not
    already contain the defect?


    -Emile
  • Marek Majkowski at Feb 10, 2012 at 4:10 pm

    On Tue, Feb 7, 2012 at 22:35, Mihir Mone wrote:
    No this problem does not occur if the message is small. The payload is
    basically database table rows that are being synched between two sites. When
    the number of rows per payload is under 10 this error does not occur. But
    once it starts getting past 15 or so I am seeing this error. The
    configuration 1 which has this error is configured for 500 rows, which
    configuration 2 is configured for 3000 rows. And configuration 2 works fine
    !!

    Yes the error is present even when you receive a message through
    "rabbitmqadmin get" command.

    Yes, I have confirmed that the original message sent to the broker at the
    remote end is OK. If you see the screenshots I have sent in the original
    email, one of them is named remote-site and the other is named local-site.
    They are nothing but dumps taken from the rabbitmq_management web UI.
    Hi,

    It is quite unlikely that this kind of bug is within RabbitMQ broker.
    It's much more probable a fault within your app or a client library.

    If you think this is a problem on RabbitMQ side, please prepare
    a (hopefully simplistic) test that reproduces the issue.

    Only then we would be able to run the test on our machines
    and confirm the problem.

    Cheers,
    Marek

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 7, '12 at 3:48a
activeFeb 10, '12 at 4:10p
posts4
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2023 Grokbase