[
https://issues.apache.org/jira/browse/QPID-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062489#comment-15062489
]
Rob Godfrey commented on QPID-6935:
-----------------------------------
Since the content is different my best guess is it is not the client causing
the error when receiving, I struggle to see a way where the client could
internally be generating multiple frames with differing content. I'd doubt
that the error would be in Camel (though I'm not very familiar with that
product) since I presume it is just managing the orchestration for receiving
from Q1 and then republishing to Q2. I'd guess that the error was either in
the message as it was sent into Q1 originally, or in the broker code that is
serialising the message from Q1 and sending it to the client. I may be
completely wrong though :)
What might be useful is if you can build a patched version of the client which
does something like checked to see if a delivery has more that 100 transfers
added to it, and if so starts turning on debug protocol logging.
> Infinite recursion resulting in huge number of Transfer objects created in
> Delivery, until OutOfMemory
> ------------------------------------------------------------------------------------------------------
>
> Key: QPID-6935
> URL: https://issues.apache.org/jira/browse/QPID-6935
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 1.0 Client
> Affects Versions: 0.32
> Environment: Linux RedHat 7
> Reporter: Leo Riguspi
> Priority: Blocker
> Attachments: Heap.png, Heap2.png, memory_dump.txt, snapshot1.png,
> snapshot2.png
>
>
> We have an Apache ActiveMQ 5.12 running for 2 months now and a Java AMQP
> client publishing a few messages every few minutes. Messages are small, less
> than 1K and are immediately consumed.
> For the second time in two months the client exploded with an OutOfMemory
> error. By analysing the memory the culprit seems to be the ArrayList of
> Trasfer objects in the Delivery. All of a sudden, for some reason it just
> keeps creating new Trasfers until the memory is full.
> We have a screenshot of the memory dump in which there are more than 49000
> Trasfer objects in the same Delivery. Unfortunately there seems to be no way
> to attach it to this issue.
> We did not find a way to reproduce the problem but it looks like some
> combination of conditions cause the SessionEndpoint::sendTransfer recursive
> method to call itself over and over, each time adding a new Transfer object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
