Rob, Re "option 1": Do you mean to check outcomes on commit and rollback amqp transaction if any of outcomes is not accepted?
Alex On 7 December 2017 at 12:49, Rob Godfrey <[email protected]> wrote: > So, two options immediately come to mind > > 1) Don't send the commit until we have received the outcomes for all > messages pulished as part of the trasnaction > 2) When creating an anonymous sender in a transactional session restrict > the acceptable outcome to accepted only (forcing the broker to close the > link if it cannot accept the message). > > In general does the client really support the released or modified outcomes > at a sender (even in the non transactional case)? > > -- Rob > > On 7 December 2017 at 13:40, Robbie Gemmell <[email protected]> > wrote: > >> Thanks Alex, I havent yet got to reading your original mails since >> returning from some time off. I'll try to soon. My first reaction from >> just the titles and without really thinking about it, is that we might >> want to change the client behaviour in some ways and the anonymous >> terminus definition in others. >> >> Robbie >> >> On 7 December 2017 at 12:00, Oleksandr Rudyy <[email protected]> wrote: >> > Hi, >> > I raised JIRA QPIDJMS-349 [1] for the problem. >> > >> > Kind Regards, >> > Alex >> > >> > [1] https://issues.apache.org/jira/browse/QPIDJMS-349 >> > >> > On 28 November 2017 at 11:09, Oleksandr Rudyy <[email protected]> wrote: >> >> Hi >> >> The broker and client behaviours are fully compliant with "Using the >> >> Anonymous Terminus for Message Routing" [1]. >> >> It conforms the requirements of section "2.2.2 Routing Errors". For >> >> the cases, when destination cannot be resolved >> >> {quote} >> >> If the source of the link supports the rejected outcome, and the >> >> message has not already been settled by the sender, then the routing >> >> node >> >> MUST reject the message. >> >> {quote} >> >> >> >> However, from JMS transaction point of view, I would expect to be able >> >> to commit the transaction only when all messages in transaction are >> >> successfully delivered. >> >> If one or more messages cannot be delivered, the JMS transaction >> >> commit should fail. >> >> >> >> It seems we are failing to deliver the JMS transaction contract. >> >> >> >> I though that work around for the issue could be to always use >> >> synchronous publishing (as exception is reported on send in this >> >> case), however, it is still possible to commit transaction >> >> successfully after failed send. >> >> As result, part of messages sent within the transaction will be >> >> successfully delivered on commit. It seems we are failing to guaranty >> >> the Atomicity of JMS transactions. >> >> >> >> The better approach could be to stop supporting "rejected" outcome for >> >> anonymous producer. That should cause the broker to detach the link >> >> with an error and mark the transaction as rollback only. >> >> Any thoughts? >> >> >> >> Kind Regards, >> >> Alex >> >> >> >> >> >> [1] https://www.oasis-open.org/apps/org/workgroup/amqp/ >> download.php/61723/amqp-anonterm-v1.0-wd03.pdf >> >> >> >> On 27 November 2017 at 22:32, Oleksandr Rudyy <[email protected]> wrote: >> >>> Hi folks, >> >>> >> >>> I recently realised that when JMS 0.24.0 publishes a message >> >>> asynchronously into non-existing destination over anonymous relay on >> >>> Qpid Broker-J v7.0 and transaction is committed, no exception is >> >>> reported to the caller of commit. I expected a JMSException to be >> >>> thrown on session.commit(), but commit was performed successfully. >> >>> This situation can potentially result in message loss, as client >> >>> application can consider such transaction successful. >> >>> >> >>> The following code snippet demonstrate the problem: >> >>> >> >>> try( Connection connection = >> >>> connectionFactory.createConnection(username, password)) >> >>> { >> >>> Session session = connection.createSession(true, >> >>> Session.SESSION_TRANSACTED); >> >>> MessageProducer messageProducer = session.createProducer(null); >> >>> Queue nonExistingQueue = session.createQueue("nonExistingQueue"); >> >>> messageProducer.send(nonExistingQueue, >> >>> session.createTextMessage("testMessage")); >> >>> session.commit(); >> >>> } >> >>> >> >>> I originally thought that it is a fault of Broker-J but after looking >> >>> into Broker code I came to a conclusion that Broker behaviour could be >> >>> spec compliant. >> >>> >> >>> On attach, the client specifies the following outcomes on the source: >> >>> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, >> >>> amqp:modified:list]} >> >>> >> >>> On receiving a message for non-existing destination, the anonymous >> >>> relay generates rejected outcome as 'rejected' outcome is in the list >> >>> of source supported outcomes. The Broker replies with settled >> >>> disposition having rejected outcome with error 'not-found'. Here is an >> >>> example of disposition >> >>> >> >>> Disposition{role=receiver,first=1,last=1,settled=true, >> state=TransactionalState{txnId=\x00\x00\x00\x00, >> outcome=Rejected{error=Error{condition=not-found,description=Unknown >> >>> destination 'nonExistingQueue'}}}} >> >>> >> >>> The JMS client receives the disposition and reports an exception >> >>> "javax.jms.InvalidDestinationException: Unknown destination >> >>> 'nonExistingQueue' [condition = amqp:not-found]" into >> >>> ExceptionListener if one is set. >> >>> If no ExceptionListener is set, the exception is logged. Thus, if >> >>> ExceptionListener is not set, a message loss can occur. >> >>> >> >>> The previous 6.x versions of Broker-J detach the link with error >> >>> 'not-found' but v7.0 simply settles with the rejected outcome. >> >>> >> >>> It seems both parties adhere to the AMQP spec requirements but the >> >>> result is surprising. I am not sure how to resolve this problem. Part >> >>> of me thinks that detaching of the link on broker side could be the >> >>> best solution of the problem, but, that would make broker behaviour >> >>> JMS specific rather than AMQP specific. Any thoughts about how to >> >>> solve this problem are highly appreciated. >> >>> >> >>> Kind Regards, >> >>> Alex >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
