[
https://issues.apache.org/jira/browse/AMQ-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545907#comment-16545907
]
Avikash Mishra commented on AMQ-7006:
-------------------------------------
Hi [~tabish121]
I did think of looping through the values just given. But at the point where I
am adding elements to my removeMessageIds I don't have access to the 'ackId'
which is the key for the pedingAcks array. So all I have is the messageId which
is a property of ActEntry. ActEntry is the value of the pedingAcks array.
For the unit tests I did try to check against different ERROR responses. The
issue is line 445 in ProtocolConverter.java. The method call to
pendingAck.onMessageAck(activemqTx); always returns null if we are 'acking' a
message that as already been acked because inside that method it checks whether
the message is in the dispatchedMessage array (which it isn't because it
removes it correctly). So the response always returns 'Unexpected ACK received
for message-id 123'
If you have any other ideas of how to write a unit test for this let me know.
I have just updated the patch with the logging changes. Please review as we
would like to push this to our prod environment in the next release.
> CLONE - STOMP protocol converter tracks pending ACKS in Client mode but
> doesn't remove all ACK'd IDs, just the one submitted.
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-7006
> URL: https://issues.apache.org/jira/browse/AMQ-7006
> Project: ActiveMQ
> Issue Type: Bug
> Components: stomp
> Affects Versions: 5.15.3
> Reporter: Avikash Mishra
> Priority: Major
> Attachments:
> AMQ-7006_Remove_all_pending_acks_that_have_been_dispatched_.patch
>
>
> The patch referenced in AMQ-5423 only addressed the memory leak for
> Client-Individual mode. Client mode is still affected as multiple messages
> are acknowledged with a single ACK. The single ACK is removed from memory
> but all the rest remain which grows over time until AMQ crashes or until the
> client session ends and all the pending ACKs are cleaned up at that point.
> At the moment we are having to regularly restart our STOMP clients to prevent
> the memory leak from causing a crash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
