Exception while transactionAbort renders ConsumerTransactionState useless

[staabm]

when a Exception occurs while ConsumerTransactionState->abort(), e.g. UnexpectedResponseException in Client->waitForReceipt() you can no longer begin new transactions.

Because of such a UnexpectedResponseException the transition from ConsumerTransactionState back to the ConsumerState does not happen. This leads to a InvalidStateException($this, __FUNCTION__) when calling ConsumerTransactionState->begin() afterwards.

Actually I am not 100% sure what the expected flow should look like, but atm I get some kind of dead-lock situation.

For the time beeing I will check why I get the underlying exception in the first place ;).

[jmglsn]

It's not easy to keep the client state clean when the underlying actions fail.
From that point of view it's ok that the machine won't continue it's work.

But it would be nice if we could provide a way to get it back to a clean state again... not yet sure how to do so.

Could you already determine the cause for the root exception?

[staabm]

I am using the client in a long running php process which sends messages inside transactions.

Because of an error in the domain logic I need to call $client->abort() in which the abort will only succeed when the openmq server repsonds with a proper receipt.

In my case the server repsonds with a message with a different receipt-id.
Not sure when/why this happens right now...

[staabm]

debugging further revealed the underlying error:

ACK: [BSS4031]: Subscriber 7320114720524992513 for message ID:531-127.0.1.1(8c:e5:15:7e:a5:36)-1-1464617789246 is not found in transaction 4507332615375683585"

I will check now where this comes from.

[jmglsn]

@staabm is this still a problem with our latest version?

[jmglsn]

@staabm Should we add a test for this or is this more or less gone?