You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Oleksandr Rudyy <or...@gmail.com> on 2017/12/07 12:00:35 UTC
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Oleksandr Rudyy <or...@gmail.com>.
Rob,
Re "option 1": Do you mean to check outcomes on commit and rollback
amqp transaction if any of outcomes is not accepted?
Alex
On 7 December 2017 at 12:49, Rob Godfrey <ro...@gmail.com> 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 <ro...@gmail.com>
> 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 <or...@gmail.com> 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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ro...@gmail.com>
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 <or...@gmail.com> 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 <ro...@gmail.com>
> 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 <ro...@gmail.com>
> 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 <ro...@gmail.com>
> >>> 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 <or...@gmail.com>
> 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 <or...@gmail.com>
> 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 <or...@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-unsubscribe@qpid.apache.org
> >>>> > For additional commands, e-mail: users-help@qpid.apache.org
> >>>> >
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >>>> For additional commands, e-mail: users-help@qpid.apache.org
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <or...@gmail.com> 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 <ro...@gmail.com> 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 <ro...@gmail.com> 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 <ro...@gmail.com>
>>> 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 <or...@gmail.com> 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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
>>>> > For additional commands, e-mail: users-help@qpid.apache.org
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Oleksandr Rudyy <or...@gmail.com>.
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 <ro...@gmail.com> 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 <ro...@gmail.com> 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 <ro...@gmail.com>
>> 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 <or...@gmail.com> 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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
>>> > For additional commands, e-mail: users-help@qpid.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ro...@gmail.com> 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 <ro...@gmail.com>
> 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 <or...@gmail.com> 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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ro...@gmail.com>
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 <or...@gmail.com> 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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Publishing message into non-existing destination over anonymous
relay within a transaction
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <or...@gmail.com> 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 <or...@gmail.com> 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 <or...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org