wrote:
> On 6 July 2016 at 17:57, Gordon Sim wrote:
> > On 06/07/16 17:42, Gordon Sim wrote:
> >>
> >> On 06/07/16 17:14, Dale Green wrote:
> >>>
> >>> I have an update on this issue.
> >>>
> >>> According to Microsoft,
xplicitly 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 wrote:
> > Sorry for the misunderstanding: The code I was test
Of course, producers are needed, not consumers.
On Tue, Jul 5, 2016 at 11:13 AM, Dale Green
wrote:
> Hi Robbie,
>
> It seems that I made multiple mistakes in evaluating the problems, but I
> finally managed to reproduce it with some very simple code.
>
> It looks that th
>> We have previously discussed stopping Proton from sending heartbeats
> >> much faster than necessary as it currently does, because it results in
> >> a significant amount of unecessary traffic/processing on servers with
> >> lots of idle clients and/or advertisin
le faster than
> necessary to avoid spurious timeouts against servers that dont
> advertise half their actual timeout, but I think it would still make
> sense for us to add an override to allow toggling it to send more
> often than it otherwise would, since it would help in situations such
&g
are being
> sent. I see you have a 121sec timeout specified client side (given the
> client advertise idle-timeout of 60.5s) too, and that should mean the
> client should be doing the idle-timeout processing at least that
> often, with the absence of any heartbeat frames being sent
Hi people,
I have another problem with Service Bus and Qpid JMS 0.9.0.
The broker uses 4 minutes idle timeout. With the sample code in the
examples, I verified that the client sends the first empty frame exactly 4
minutes after the consumer has connected. After that, Qpid sends an empty
frame eve
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
wrote:
> On 29 June 2016 at 11:08, Dale Gree
doesn't send anything anymore.
On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell
wrote:
> On 28 June 2016 at 17:00, Dale Green wrote:
> > Hi people,
> >
> > I have a problem using Qpid JMS 0.9 with Service Bus.
> >
> > The use case is the following:
> > I
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 t
Hi,
Are there any plans to upgrade Qpid Jca to support AMQP 1.0?
Or maybe there is already some work in progress or another project for this?
Thanks!
rg/releases/qpid-jms-0.9.0/docs/index.html#logging
> for details of hwo to enable it.
>
> Robbie
>
> On 22 June 2016 at 10:00, Dale Green wrote:
> > Hi,
> >
> > I am trying to communicate with Service Bus for Windows Server via AMQP
> and
> > found this p
Hi,
I am trying to communicate with Service Bus for Windows Server via AMQP and
found this problem.
This was tried with Qpid JMS 0.9.0 and also with the latest snapshot. If
there are no messages on the queue when I call receive(timeout>0), the call
blocks forever. Sending a message to the same qu
13 matches
Mail list logo
