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 <oru...@gmail.com> 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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
