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]
