qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Question about transactional model of JMS client
Date Wed, 08 Feb 2017 10:11:18 GMT
On 8 February 2017 at 09:59, Oleksandr Rudyy <orudyy@gmail.com> wrote:
> Rob, Robbie,
>
> Thanks for explaining the reasons behind using "transaction retiring"
> in JMS client.
>
> Regarding Rob's question:
> What is the use case you see where being unable to send unsettled
> dispositions in a transaction would be a problem?
>
> I see a problem here only when Links for p2p are not closed as part of
> Session#close(). It seems the case with current implementation of
> Session#close(). When I was testing it, the detach commands had not
> been sent at all. Thus, if unsettled dispositions were to be sent from
> client, that would result in keeping of the acquired messages in
> acquired state. I think that client should be sending detaches on
> session close for opened links but that was not implemented yet.
>

Not sending detaches was deliberate, the links are implicitly detached
when the session goes away. Given the link and terminus expiry options
used in most cases this also implicitly destroys the source and its
hold on the any messages. The client also doesn't send unsettled
dispositions currently so far as I am aware.

> Another reasons made me looking into a "transactional acquisition" is
> a case when transacted session is closed  with in progress
> transactions ( when a discharge with fail=true is sent) and the client
> has a credit. When transaction is rolled back the acquired messages
> are released and resend back to the client. It looks like
> "transactional acquisition" would solve this unnecessary message
> transfers to the client, as it includes the draining of credits before
> the discharge.

It isn't unecessary - the delivery count gets incremented in the
process, something the client would do explicitly and individually if
using transactional acquisition, which would again lead to the
messages being redelivered from the server.

> It seems that with "transactional retirement" this
> issue can be work around by draining flow on session#close as a first
> thing before discharging the in-progress transactions and detaching
> the links. It looks like stopping the flow is right thing to do on
> Session#close anyway.

As I see Rob has ninja'd me yet again, I'll stop typing now :P

>
> Kind Regards,
> Alex
>
>
>
> On 6 February 2017 at 15:07, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
>> In terms of transactional retirement, the "issue" you highlight only
>> applies to links for which we expect the broker to hold on to ... which, in
>> the case of the JMS client, is durable subscriptions only.  Moreover, since
>> the client anyway cannot deal with restoring unsettled state, the client
>> doesn't send its transactional dispositions unsettled (as Robbie has
>> already pointed out), so the issue doesn't even occur.
>>
>> What is the use case you see where being unable to send unsettled
>> dispositions in a transaction would be a problem?
>>
>> In passing - I also agree with Robbie - I think transactional acquisition
>> is a niche use case, and actually really hard to use.
>>
>> -- Rob
>>
>> On 6 February 2017 at 15:21, Robbie Gemmell <robbie.gemmell@gmail.com>
>> wrote:
>>
>>> Transactional acquisition is actually quite awkward, I'm not aware of
>>> any client that uses it. Proton can't even support it currently I
>>> believe.
>>>
>>> You need to know the transaction id before you flow any credit for it,
>>> which adds extra round trips. When you then discharge the transaction,
>>> any outstanding credit is not revoked, but it no longer applies to the
>>> indicated transaction any more, meaning if you flowed more credit than
>>> there are messages consumed in the transaction you now either need to
>>> ensure that before you discharge there is no outstanding credit or
>>> messages in flight, so more round trips, or perhaps revert to doing
>>> transactional acquisition with the remaining credit/messages arriving
>>> that arent consumed in the earlier transaction. Another thing to
>>> consider is that with transactional-retirement, the 'failed'
>>> deliveries during a rollback can as desired lead to the delivery-count
>>> being incremented (via the default outcome; the JMS client indeed
>>> doesnt send dispositions that arent settled when it is doing
>>> transactions, or probably ever currently) whereas those that remained
>>> live need not, though the client would then be free to do that of
>>> course, but that would then require they be redelivered to the client
>>> as already happens in the retirement case.
>>>
>>> Robbie
>>>
>>> On 6 February 2017 at 13:30, Oleksandr Rudyy <orudyy@gmail.com> wrote:
>>> > Hi,
>>> > I would like to ask why "transactional retirement" is used by jms
>>> > client instead of "transactional acquisition"?
>>> >
>>> > I am sorry if I missed any previous discussion about implementation of
>>> > amqp transactions with JMS client. From my point of view the
>>> > 'transactional acquisition' model would fit better the stateless
>>> > nature of JMS client.
>>> >
>>> > The reason why I am thinking so is that with "transactional
>>> > retirement" any unsettled messages would remain acquired on
>>> > transaction rollback as per section 4.4.2 "Transactional Retirement"
>>> > last sentence "In the event of a controller-initiated rollback (a
>>> > discharge where the fail flag is set to true) or a resource-initiated
>>> > rollback (the discharge message being rejected, or the link to the
>>> > coordinator being detached with an error), the outcome will not be
>>> > applied, and the deliveries will still be “live” and will remain
>>> > acquired by the controller, i.e., the resource can expect the
>>> > controller to request a disposition for the delivery (either
>>> > transactionally on a new transaction, or non-transactionally)", or as
>>> > per 4.4.4.2 "Transactional Retirement"( "Delivery Sent Unsettled By
>>> > Resource; Controller Does Not Settle").
>>> >
>>> > It seems that JMS client should never send disposition for unsettled
>>> > transfers in transaction. Otherwise, if link is detached without
>>> > close=true, the transefered message would be in acquired state and if
>>> > JMS client will not reattach the link, the transfers would be acquired
>>> > forever.
>>> >
>>> > Out of curiosity, why 'transactional acquisition' is not used by the
>>> > jms client for jms transaction implementation? It looks to me like a
>>> > more attractive approach when client does not keep the states. Am I
>>> > missing something?
>>> >
>>> >
>>> > 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


Mime
View raw message