Hello,

Below is a Stomp log for a successful test case which uses a Topic
destination and two subscribers:

* two different Stomp client connections subscribe to a topic (Stomp
header frame: "destination:/topic/TestTopic")
* the third Stomp client connection sends two messages to this topic
* the two subscribed clients await the messages

However, the tests show many cases where the broker does not deliver all
messages to both clients. After the first message, one / two /three
remaining message are received or not.

Maybe there is an error in the Stomp headers of my client for the send
or subscribe frames?

All other unit tests - with Queue destinations - pass with 100% success.

I will also try to debug it server-side using the management plugin.


send:
CONNECT
login:guest
passcode:guest



received:
CONNECTED
session:session-YVVx2qdlhn5kZwGPvyuE1Q==
heartbeat:0,0
version:1.0


send:
SUBSCRIBE
destination:/topic/TestTopic
ack:auto
id:{8D37586E-5D3C-4CCA-9584-9826B53B2B91}



send:
CONNECT
login:guest
passcode:guest



received:
CONNECTED
session:session-i9FpncmwinfGuLXyq1OZIQ==
heartbeat:0,0
version:1.0


send:
SUBSCRIBE
destination:/topic/TestTopic
ack:auto
id:{5638253D-3371-4418-8193-CFC38D2C39BD}



send:
CONNECT
login:guest
passcode:guest



received:
CONNECTED
session:session-GIjthMML0HAing/aF+Wtxw==
heartbeat:0,0
version:1.0


send:
SUBSCRIBE
destination:/topic/TestTopic
ack:auto
id:{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}



send:
SEND
destination:/topic/TestTopic
content-length:5
delivery-mode:2
content-type:text/plain

msg 1

send:
SEND
destination:/topic/TestTopic
content-length:5
delivery-mode:2
content-type:text/plain

msg 2

received:
MESSAGE
delivery-mode:2
content-type:text/plain
subscription:{5638253D-3371-4418-8193-CFC38D2C39BD}
destination:/topic/TestTopic
message-id:T_{5638253D-3371-4418-8193-CFC38D2C39BD}@@session-i9FpncmwinfGuLXyq1O
ZIQ==@@1
content-length:5

msg 1
received:
MESSAGE
delivery-mode:2
content-type:text/plain
subscription:{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}
destination:/topic/TestTopic
message-id:T_{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}@@session-GIjthMML0HAing/aF+W
txw==@@1
content-length:5

msg 1
received:
MESSAGE
delivery-mode:2
content-type:text/plain
subscription:{5638253D-3371-4418-8193-CFC38D2C39BD}
destination:/topic/TestTopic
message-id:T_{5638253D-3371-4418-8193-CFC38D2C39BD}@@session-i9FpncmwinfGuLXyq1O
ZIQ==@@2
content-length:5

msg 2
received:
MESSAGE
delivery-mode:2
content-type:text/plain
subscription:{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}
destination:/topic/TestTopic
message-id:T_{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}@@session-GIjthMML0HAing/aF+W
txw==@@2
content-length:5

msg 2
send:
DISCONNECT



send:
DISCONNECT



send:
DISCONNECT

Regards
--
Michael Justin
habarisoft - Enterprise Messaging Software for Delphi?
http://www.habarisoft.com/

Search Discussions

  • Rob Harrop at Apr 15, 2011 at 2:44 pm
    Michael,

    Are you referring to the tests distributed with Rabbit or do you have
    your own test code that you are running?

    I can take a quick guess at why this is failing. The SUBSCRIBE frames
    are processed asynchronously. So, if you issue a few SUBSCRIBEs followed
    by a few SENDs then you might not see MESSAGE frames for the SUBSCRIBEs
    that are yet to finish processing.

    The best way to guarantee that a SUBSCRIBE has finished is to provide a
    receipt: header and then wait for the receipt. You'll see this pattern
    quite a lot in the RabbitMQ STOMP tests.

    Regards,

    Rob
    On 14/04/11 08:13, Michael Justin wrote:
    Hello,

    Below is a Stomp log for a successful test case which uses a Topic
    destination and two subscribers:

    * two different Stomp client connections subscribe to a topic (Stomp
    header frame: "destination:/topic/TestTopic")
    * the third Stomp client connection sends two messages to this topic
    * the two subscribed clients await the messages

    However, the tests show many cases where the broker does not deliver all
    messages to both clients. After the first message, one / two /three
    remaining message are received or not.

    Maybe there is an error in the Stomp headers of my client for the send
    or subscribe frames?

    All other unit tests - with Queue destinations - pass with 100% success.

    I will also try to debug it server-side using the management plugin.


    send:
    CONNECT
    login:guest
    passcode:guest



    received:
    CONNECTED
    session:session-YVVx2qdlhn5kZwGPvyuE1Q==
    heartbeat:0,0
    version:1.0


    send:
    SUBSCRIBE
    destination:/topic/TestTopic
    ack:auto
    id:{8D37586E-5D3C-4CCA-9584-9826B53B2B91}



    send:
    CONNECT
    login:guest
    passcode:guest



    received:
    CONNECTED
    session:session-i9FpncmwinfGuLXyq1OZIQ==
    heartbeat:0,0
    version:1.0


    send:
    SUBSCRIBE
    destination:/topic/TestTopic
    ack:auto
    id:{5638253D-3371-4418-8193-CFC38D2C39BD}



    send:
    CONNECT
    login:guest
    passcode:guest



    received:
    CONNECTED
    session:session-GIjthMML0HAing/aF+Wtxw==
    heartbeat:0,0
    version:1.0


    send:
    SUBSCRIBE
    destination:/topic/TestTopic
    ack:auto
    id:{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}



    send:
    SEND
    destination:/topic/TestTopic
    content-length:5
    delivery-mode:2
    content-type:text/plain

    msg 1

    send:
    SEND
    destination:/topic/TestTopic
    content-length:5
    delivery-mode:2
    content-type:text/plain

    msg 2

    received:
    MESSAGE
    delivery-mode:2
    content-type:text/plain
    subscription:{5638253D-3371-4418-8193-CFC38D2C39BD}
    destination:/topic/TestTopic
    message-id:T_{5638253D-3371-4418-8193-CFC38D2C39BD}@@session-i9FpncmwinfGuLXyq1O

    ZIQ==@@1
    content-length:5

    msg 1
    received:
    MESSAGE
    delivery-mode:2
    content-type:text/plain
    subscription:{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}
    destination:/topic/TestTopic
    message-id:T_{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}@@session-GIjthMML0HAing/aF+W

    txw==@@1
    content-length:5

    msg 1
    received:
    MESSAGE
    delivery-mode:2
    content-type:text/plain
    subscription:{5638253D-3371-4418-8193-CFC38D2C39BD}
    destination:/topic/TestTopic
    message-id:T_{5638253D-3371-4418-8193-CFC38D2C39BD}@@session-i9FpncmwinfGuLXyq1O

    ZIQ==@@2
    content-length:5

    msg 2
    received:
    MESSAGE
    delivery-mode:2
    content-type:text/plain
    subscription:{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}
    destination:/topic/TestTopic
    message-id:T_{CD4ED764-2A88-4D7A-80CC-F9FA37901D74}@@session-GIjthMML0HAing/aF+W

    txw==@@2
    content-length:5

    msg 2
    send:
    DISCONNECT



    send:
    DISCONNECT



    send:
    DISCONNECT

    Regards
  • Michael Justin at Apr 19, 2011 at 5:09 pm

    Am 15.04.2011 16:44, Rob Harrop wrote:

    Are you referring to the tests distributed with Rabbit or do you have
    your own test code that you are running?
    These are tests for my Delphi / Free Pascal client library, which are
    now close to the first release
    I can take a quick guess at why this is failing. The SUBSCRIBE frames
    are processed asynchronously. So, if you issue a few SUBSCRIBEs followed
    by a few SENDs then you might not see MESSAGE frames for the SUBSCRIBEs
    that are yet to finish processing.
    This was my first thought too - so I inserted a long delay (several
    seconds) between the subscribe and the send. It did not solve the
    problem, the broker did not send all incoming messages to all
    subscribers. I could not find any pattern, so I was happy to see your
    answer and tried it today
    The best way to guarantee that a SUBSCRIBE has finished is to provide a
    receipt: header and then wait for the receipt. You'll see this pattern
    quite a lot in the RabbitMQ STOMP tests.
    Adding a receipt header fixed the problem. However, this is not
    specified in the Stomp documentation (the receipt header is optional).
    (Maybe the requirement of using a receipt header should be added to the
    RabbitMQ Stomp adapter docs.)

    Thanks and have a nice day

    Michael Justin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedApr 14, '11 at 7:13a
activeApr 19, '11 at 5:09p
posts3
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Michael Justin: 2 posts Rob Harrop: 1 post

People

Translate

site design / logo © 2022 Grokbase