On 6 July 2016 at 17:50, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> Hi Dale,
>
> It isnt invalid from a protocol perspective, as dispositions only
> actually refer to session-scoped information, not link
> (consumer/producer) scoped information. I deleted an overly
> complicated description <here> of why that is. ServiceBus isnt
> necessarily wrong in ignoring the dispositions given some of those
> complicated bits I've deleted (in parts to do with things Gordon
> referred to), but in doing so it itself indicating the messages should
> not be locked any more: if the dispositions are ignored, then noone
> can release or consume those messages at that point, so why continue
> to lock them?
>
> The client doesnt currently reduce credit to 0 before detaching as
> doing so would only mainly just add an extra round trip to the
> process.
Well, to be entirely accurate, it does have one way, configuring 0
prefetch, thats just not possible here as it cant worth against
ServiceBus. Thats also the same mechanism we would likely use to
implement such behaviour in the non-0 prefetch case though, meaning
that approach also wouldnt work against ServiceBus currently.
>
> (As an aside, it is actually Proton sending the disposistions
> implicitly rather than the client doing so directly)
>
> Robbie
>
> On 6 July 2016 at 17:14, Dale Green <green.dale1...@gmail.com> wrote:
>> I have an update on this issue.
>>
>> According to Microsoft, state=Released is supported and now I can confirm
>> that this is true. If the message is released during the lifetime of the
>> consumer (before Detach), the same message is immediately unlocked and is
>> available for the same consumer or others depending on the credit.
>>
>> However, what happens with Qpid JMS is that messageConsumer.close() first
>> sends a Detach frame and after that the Disposition frames if any. Is this
>> correct from protocol point of view, as Service Bus seems to ignore such
>> dispositions?
>>
>> Is there any way to set the credit to 0, send the Dispositions, and then
>> Detach?
>>
>> Thanks!
>>
>> On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell <robbie.gemm...@gmail.com>
>> wrote:
>>
>>> Thanks for the update. That seems to confirm that theres not much the
>>> client can do to help here, as both of the mechanisms it could use to
>>> assist in this situation (explicitly releasing unconsumed messages, or
>>> doing no prefetching to begin with) appear to be running into server
>>> bugs, in this case the snippet Gordon linked to.
>>>
>>> Robbie
>>>
>>> On 30 June 2016 at 15:42, Dale Green <green.dale1...@gmail.com> wrote:
>>> > Sorry for the misunderstanding: The code I was testing is actually
>>> closing
>>> > the consumer explicitly.
>>> >
>>> > However, I tested now the Receiver example and can confirm, that it
>>> doesn't
>>> > matter for the server if the consumer is closed or not.
>>> > I can see that
>>> > messageConsumer.close();
>>> > produces such log lines for the prefetched messages:
>>> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
>>> > state=Released{}, batchable=false}
>>> >
>>> > But the same messages are still locked for the lock duration.
>>> >
>>> >
>>> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
>>> robbie.gemm...@gmail.com>
>>> > wrote:
>>> >
>>> >> On 29 June 2016 at 11:08, Dale Green <green.dale1...@gmail.com> wrote:
>>> >> > Hi Robbie,
>>> >> >
>>> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
>>> some
>>> >> > more info, which can be useful for other people.
>>> >> >
>>> >> > Closing the consumer explicitly didn't help (it's closed on session
>>> close
>>> >> > anyway). However, I have the feeling that the lifetime of the consumer
>>> >> does
>>> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
>>> >> lock
>>> >> > the messages for longer than the lock duration).
>>> >> >
>>> >>
>>> >> After sending my last reply to Gordon, I noticed something in your
>>> >> wording that I'd now like to double check. When I asked if you tried
>>> >> closing the consumer explicitly I meant before closing the session
>>> >> object, i.e:
>>> >> consumer.close();
>>> >> session.close();
>>> >>
>>> >> Can you confirm that is what you updated your code to do?
>>> >>
>>> >> > Setting the prefetch value to 1 didn't help as the next message comes
>>> to
>>> >> > the consumer immediately after receive(). So, there could be 0 or 1
>>> >> locked
>>> >> > messages after each consumer.
>>> >> >
>>> >> > Setting the prefetch value to 0 brings me back to the drain problem:
>>> >> > Service Bus doesn't answer anything after the sent packet with
>>> >> 'drain=true'
>>> >> > , so receive() is blocked forever. However, there are some (probably
>>> >> empty)
>>> >> > AMQP packets sent after some time, but Qpid doesn't send anything
>>> >> anymore.
>>> >> >
>>> >> >
>>> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
>>> >> robbie.gemm...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> >> On 28 June 2016 at 17:00, Dale Green <green.dale1...@gmail.com>
>>> wrote:
>>> >> >> > Hi people,
>>> >> >> >
>>> >> >> > I have a problem using Qpid JMS 0.9 with Service Bus.
>>> >> >> >
>>> >> >> > The use case is the following:
>>> >> >> > I want to create a connection, session, and a queue consumer and
>>> >> receive
>>> >> >> 0
>>> >> >> > or 1 messages within a given timeout. That is, receive(timeout) is
>>> >> called
>>> >> >> > only once. Immediately after that, the session and the connection
>>> are
>>> >> >> > closed.
>>> >> >> >
>>> >> >> > The problem is:
>>> >> >> > The consumer may receive multiple messages during its lifetime
>>> (which
>>> >> the
>>> >> >> > client code doesn't even see, because receive is called only once).
>>> >> For
>>> >> >> > Service Bus, all this means peek-and-lock, so the messages that
>>> were
>>> >> sent
>>> >> >> > to the Qpid client are locked for the time set in the "Lock
>>> Duration"
>>> >> >> > property of the queue (default value is 30s/60s, Azure/Windows),
>>> and
>>> >> >> > therefore they are unavailable for other Qpid consumers for a
>>> certain
>>> >> >> > period of time. I would expect that something like the method
>>> >> Abandon()
>>> >> >> > from the C# API should happen on session close.
>>> >> >> >
>>> >> >> > So:
>>> >> >> > Is this a bug, feature, or I need to configure/call something in a
>>> >> >> > different way?
>>> >> >> >
>>> >> >> > Thanks!
>>> >> >>
>>> >> >> My guess is that ServiceBus is not taking the consumers implicit
>>> >> >> detachment when the session ends as reason to release the messages.
>>> >> >> Perhaps try explicitly closing the MessageConsumer (I'm taking your
>>> >> >> text above literally, such that you arent doing so currently) to see
>>> >> >> if that prods it into doing so?
>>> >> >>
>>> >> >> Another thing you could to help is if you know you want at most 1
>>> >> >> message is to only give 1 message credit at a time (setting the
>>> >> >> prefetch config to 1 or 0...though the earlier server issue you ran
>>> >> >> into around 'drain' behaviour may mean this doesnt work so well)
>>> >> >>
>>> >> >> Robbie
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> >> >> For additional commands, e-mail: users-h...@qpid.apache.org
>>> >> >>
>>> >> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> >> For additional commands, e-mail: users-h...@qpid.apache.org
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
