On 8 Feb 2007, at 17:22, Gordon Sim wrote:
Martin Ritchie wrote:
TxRollback seems to have problems both in our Qpid Java
implementation
and the AMQP method.
What is the problem with the AMQP method?
When I wrote the JIRA I felt that the TxRollback should leave the
channel suspended so the client can ensure that they clean their
prefetch catch before re-flowing the messages. However as I created a
JIRA over on AMQP for clarification about this I wondered if doing
the clean up on the TxRollbackOk handler would be sufficient. I was
going from the code that was already their in the client. I had a
mental block on the fact that there could be a handler for the Ok. I
don't believe we have one currently. I'll look at that in the morning.
This was related to the Basic.Recover method that was added in the
Qpid Java client for recovery. It is async and so needs flow control
"locking" around it .. If it were synchronous then it took could have
a Ok handler to clean up.
Does that seem right to you? I know your not that familiar with the
Java code. Sometimes it helps to take a step back and look at how
something is being fixed and not just that it gets fixed.
:)
--
Martin
