[ https://issues.apache.org/jira/browse/QPID-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183953#comment-13183953 ]
Rob Godfrey commented on QPID-3604: ----------------------------------- The commit associated with this JIRA doesn't seem to completely match the description - rather than releasing all the messages *only* when connection.stop() is called, it instead does so every time the channel is asked to suspend. While connection.stop() is one occasion when this happens, it is by no means the only one (e.g it is called every time a new consumer is registered, or if flow control is activated on a "no-ack" session). I also note that one of the tests regularly failing after this commit is the new test added in the same commit. Can I suggest that this change is reverted since these failures are making it difficult test whether other new work is causing failures or not. > If the connection is stopped the client should release all it's messages in > the prefetch buffer > ----------------------------------------------------------------------------------------------- > > Key: QPID-3604 > URL: https://issues.apache.org/jira/browse/QPID-3604 > Project: Qpid > Issue Type: Bug > Components: Java Client > Affects Versions: 0.14 > Reporter: Rajith Attapattu > Assignee: Rajith Attapattu > Fix For: 0.15 > > > When connection.stop() is called, the JMS client should release all it's > messages in the prefetch buffer. > For all we know, the connection may never be started (depending on > application logic) and those messages will be stuck on the prefetch buffer. > Releasing it will allow another consumer to get them (in the case of a shared > queue case). > Another less severe but nevertheless an undesirable side affect of this is > the client getting more messages than required by the capacity or prefetch > arguments. See QPID-3602 > This may not be a big issue if the client is prefetching a few messages, but > if prefetching something like 5000 messages, this could potentially cause a > lethal spike in the clients memory usage. > Even in low capacity/prefetch values, if the messages are large (say in the > mega byte range) this could potentially put the client under memory pressure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org