Robbie, Your option 1 is not supported currently by Broker-J :(. We need to change the broker to close the link if message is sent pre-settled but the destination rejects it. When Keith is back we will discuss implementation of the change on the broker side (hopefully, in v7.0.1). I do like your option 1. I am not sure how we missed it in v7.0 :(.
Kind Regards, Alex On 7 December 2017 at 14:17, Robbie Gemmell <[email protected]> wrote: > I had a different immediate thought, of making the client send > pre-settled transacted messages, and having the server then treat them > the same way it already has to handle such messages otherwise. > > Option 1) is something the client effectively already did at one > point, for 0.20.0, where Alex reported the resulting reduced > performance as a bug. I dont think 2) is a nice option. > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
