[DISPATCH-1045] Sometimes close connetion after releasing partial multi-frame messsage

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.1.0
• Fix Version/s: 1.2.0
• Component/s: Router Node
• Assignee: Ganesh Murthy
• Reporter: Alan Conway
• Created: 20/Jun/18 18:33
• Updated: 02/Oct/19 17:55
• Resolved: 28/Jun/18 13:32

Description

Since DISPATCH-1012 the router releases undeliverable deliveries.

In the case of a multi-frame delivery, it is possible for dispatch to release it before the entire delivery has been received. Presently dispatch settles such deliveries and advances its link. That means that if another transfer for the same delivery arrives, dispatch regards it as a new message with an invalid delivery-id and closes the connection. Since the release is asynchronous, there's no way for the client to avoid this possibility.

Worth checking the spec but I suspect we should be dropping the extra data rather than closing the connection. Need to investigate how this would work in proton - I think we'd update the delivery without settling it and then wait for the remote to settle before finally throwing it away.

 

Issue Links

• is related to: DISPATCH-1110 Intermittent router hang while running QIT's AMQP large content test
• relates to: PROTON-1914 [c] receiver cannot settle an incomplete incoming message
• relates to: DISPATCH-1012 Release undeliverable deliveries, don't hold them
• links to: GitHub Pull Request #328