I'd actually argue the other behaviour the spec outlines is the nicer approach in general, rejecting a subsequent attempt to commit, rather than just closing the coordinator link, but the JMS client handles either I believe.
On 7 December 2017 at 14:37, Oleksandr Rudyy <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
