> > > using
> > > > > > > a
> > > > > > > smaller number that we dont want to use, because we
> > > > > > > followed
> > > > > > > the
> > > > > > > specs
> > > >
t; > >
> > > > CC'ing user's list
> > > >
> > > > Given the interpretations of the spec discussed below is the
> > > > way
> > > > Proton handles this functionality inconsistent with itself?
> > > >
> > >
=qpid-proton.git;a=blob;f=proton-c/src/transport/transport.c;h=cdecfd291139acfb1c90698677abc0efc4056f50;hb=HEAD#l2539
- Original Message -
> From: "Robbie Gemmell"
> To: dev@qpid.apache.org
> Cc: us...@qpid.apache.org
> Sent: Monday, October 17, 2016 12:32:13 PM
> Subject
On 17 October 2016 at 16:57, Alan Conway wrote:
> On Fri, 2016-09-30 at 14:40 +0100, Rob Godfrey wrote:
>> I don't think it's a bug - it's a completely valid (if chatty)
>> choice.
>>
>> To my mind the semantics of the field are this:
>>
>> The sender of the open frame is saying "if I do not recei
> 2) Proton interprets the idle-timeout in the received open as the
> > > actual time out interval, and pessimistically ;) generates
> > > heartbeats as 1/2 that value.
> > >
> > > Is this a bug in the Proton implementation?
> > >
> > > -K
&
1/2 that value.
> >
> > Is this a bug in the Proton implementation?
> >
> > -K
> >
> > - Original Message -
> > >
> > > From: "Alan Conway"
> > > To: dev@qpid.apache.org
> > > Sent: Thursday, September 2
on?
>
> -K
>
> - Original Message -
>> From: "Alan Conway"
>> To: dev@qpid.apache.org
>> Sent: Thursday, September 29, 2016 9:11:51 AM
>> Subject: Re: API and terms: idle-time-out and heartbeat intervals.
>>
>> On Wed, 2016-09-28 at 22:33 +0100
pen as the actual time
> out interval, and pessimistically ;) generates heartbeats as 1/2 that value.
>
> Is this a bug in the Proton implementation?
>
> -K
>
> - Original Message -
>> From: "Alan Conway"
>> To: dev@qpid.apache.org
>> Sent:
t; Off topic: why is this on the dev list?
> > >
> > >
> > > On Wed, Sep 28, 2016 at 12:36 PM, Alan Conway
> > > wrote:
> > >
> > > >
> > > > On Wed, 2016-09-28 at 10:13 -0400, Ken Giusti wrote:
> > > > >
> > >
wrote:
> > > >
> > > > I've had a hand in the way Proton/C interprets the meaning of
> > > > 'idle-
> > > > timeout' and I've never liked the solution. I think Proton/C's
> > > > behavior is not 'pessimistic' as mu
; I've had a hand in the way Proton/C interprets the meaning of
>> > > 'idle-
>> > > timeout' and I've never liked the solution. I think Proton/C's
>> > > behavior is not 'pessimistic' as much as it is 'conservative' for
gt; needless idle frame chattiness when both ends are Proton-based.
>> >
>> > - Original Message -
>> > >
>> > > From: "Rob Godfrey"
>> > > To: "qpid"
>> > > Sent: Wednesday, September 28, 2016 6:19:05 AM
&
uot;Rob Godfrey"
>> To: "qpid"
>> Sent: Wednesday, September 28, 2016 6:19:05 AM
>> Subject: Re: API and terms: idle-time-out and heartbeat intervals.
>>
>> I agree that specifying that the communicated figure should be "half"
>> the "
ortunately ends up with a
> > > needless idle frame chattiness when both ends are Proton-based.
> > >
> > > - Original Message -
> > > >
> > > >
> > > > From: "Rob Godfrey"
> > > > To: "qpid"
ed.
> >
> > - Original Message -
> > >
> > > From: "Rob Godfrey"
> > > To: "qpid"
> > > Sent: Wednesday, September 28, 2016 6:19:05 AM
> > > Subject: Re: API and terms: idle-time-out and heartbeat intervals.
> >
liked the solution. I think Proton/C's
> behavior is not 'pessimistic' as much as it is 'conservative' for the
> sake of interoperability. This, unfortunately ends up with a
> needless idle frame chattiness when both ends are Proton-based.
>
> - Original Messag
vative' for the
> sake of interoperability. This, unfortunately ends up with a
> needless idle frame chattiness when both ends are Proton-based.
>
> - Original Message -
> >
> > From: "Rob Godfrey"
> > To: "qpid"
> > Sent:
ends up with a needless idle frame chattiness when both
ends are Proton-based.
- Original Message -
> From: "Rob Godfrey"
> To: "qpid"
> Sent: Wednesday, September 28, 2016 6:19:05 AM
> Subject: Re: API and terms: idle-time-out and heartbeat intervals.
>
I agree that specifying that the communicated figure should be "half"
the "actual" timeout was a mistake.
What the spec should have tried to communicate is that the sender
should communicate a value somewhat less than the period it uses to
determine that the connection has actually timed-out to al
On 27 September 2016 at 22:24, Alan Conway wrote:
> On Tue, 2016-09-27 at 15:37 -0400, Alan Conway wrote:
>> I want to clarify and document the meaning of these terms for our
>> APIs,
>> presently I can't find anywhere where they are documented clearly.
>>
>> The AMQP spec says: "Each peer has its
On Tue, 2016-09-27 at 15:37 -0400, Alan Conway wrote:
> I want to clarify and document the meaning of these terms for our
> APIs,
> presently I can't find anywhere where they are documented clearly.
>
> The AMQP spec says: "Each peer has its own (independent) idle
> timeout.
> At connection open e
I want to clarify and document the meaning of these terms for our APIs,
presently I can't find anywhere where they are documented clearly.
The AMQP spec says: "Each peer has its own (independent) idle timeout.
At connection open each peer communicates the maximum
period between activity (frames) o
22 matches
Mail list logo
