Tim, Robbie,
Thanks for your quick responses. I was wracking my brain, since our unit and
integration tests also guaranteed that these values were used as they came
in off the wire. It turns out that a misspelled variable in our trace log
was leading me astray, printing out our default
On 22 October 2015 at 17:21, mbroadst wrote:
> Hi Tim,
> Okay, I'm going by section 2.4.5 of the spec here where it indicates: "At
> connection open each peer communicates the maximum period between activity
> (frames) on the connection that it desires from its partner." Then
Hi Tim,
Okay, I'm going by section 2.4.5 of the spec here where it indicates: "At
connection open each peer communicates the maximum period between activity
(frames) on the connection that it desires from its partner." Then in
section 2.4.1 we have: " After establishing or accepting a TCP
On 10/22/2015 12:21 PM, mbroadst wrote:
> Hi Tim,
> Okay, I'm going by section 2.4.5 of the spec here where it indicates: "At
> connection open each peer communicates the maximum period between activity
> (frames) on the connection that it desires from its partner." Then in
> section 2.4.1 we
On 10/21/2015 02:15 PM, mbroadst wrote:
> Hi,
> I'm a maintainer for a node.js amqp 1.0 module (node-amqp10), and we have a
> user currently facing issues connecting to an ActiveMQ instance. It seems
> that when our client sends our default idle timeout of 12ms in the
> initial open
Hi,
I'm a maintainer for a node.js amqp 1.0 module (node-amqp10), and we have a
user currently facing issues connecting to an ActiveMQ instance. It seems
that when our client sends our default idle timeout of 12ms in the
initial open performative, ActiveMQ is not honoring that value. ActiveMQ