[
https://issues.apache.org/jira/browse/DISPATCH-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623902#comment-16623902
]
Chuck Rolke commented on DISPATCH-1125:
---------------------------------------
The issue appears to be rooted in a race condition when a message has multiple
destinations. Another observation was:
* if there was no receiver on the middle router then the middle router would
forward milliions of messages across the network no problem
* as soon as the receiver was added then the problem would reappear
After extensive logging the error pattern emerged.
* A message bound for two destinations arrives
* The message is copied and sent to the first destination
* The whole message is sent to the first destination. Since there is no other
destination yet the message buffers are freed as they are sent.
* The message is copied again for the second destination.
* The first buffer is sent to the second destination but that buffer is in the
free list. After sending the first buffer the send function marches off sending
buffers in the free list.
See attached log file.
> AMQP framing errors on forwarded multicast messages
> ---------------------------------------------------
>
> Key: DISPATCH-1125
> URL: https://issues.apache.org/jira/browse/DISPATCH-1125
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
> Affects Versions: 1.3.0
> Reporter: Chuck Rolke
> Priority: Major
>
> These errors show up using the same setup described in DISPATCH-1124.
> A three-router linear network uses a wireless connection for the interrouter
> links.
> Messages are injected into a router at one end of the chain and are forwarded
> to receivers on the other two routers.
> * The receiver attached to the router in the middle may receive tens of
> millions of messages before getting an underflow.
> * The receiver attached to the router at the far end of the chain may file
> as soon as 25 messages or as late as several thousand messages.
> * Messages are text strings 1,443 bytes long
> Some observations:
> * Normal transfer frames have transport size of 0x5ec bytes.
> * Messages that fail with underrun commonly have a size of 0x1aa bytes. It
> is not always 0x1aa but that number shows up in consecutive runs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
