Yes - I think the "best" behaviour is, where a pre-settled message cannot be fully processed by a queue/exchange/whatever then have the transactional resource (queue / exchange / whatever) logically mark the transaction as "rollback only" (i.e. failed), and then reject any attempt to commit such a transaction.
-- Rob On 7 December 2017 at 15:55, Robbie Gemmell <[email protected]> wrote: > 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] > >
