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 have: " After establishing or accepting a TCP connection > and sending the protocol header, each peer MUST send an open frame before > sending any other frames. The open frame describes the capabilities and > limits of that peer". This is where my concept of a handshake (or > "agreement", if you will) came from. > > I can confirm that our client sends out an Open performative with our > desired timeout in it (120s), and ActiveMQ responds with a corresponding > Open performative with exactly the same value I send (so 120s in this case). > >From my perspective this would appear that ActiveMQ has "agreed" to the > terms of the idle timeout and should therefore use that value for its > internal bookkeeping. Nowhere in this initial connection setup does the > value 30s appear (or rater 30000 for ms), ActiveMQ just seems to send back > the same idle-time-out value I send. > > I have fairly verbose frame traces if that would be of assistance on your > side? > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/ActiveMQ-does-not-seem-to-honor-the-agreed-upon-idle-time-out-tp4703244p4703290.html > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. > Our unit tests would tend to disagree with the assertion that the broker takes the peer value and returns it, perhaps you have configured the broker's AMQP transportConnector with a non-default idleTimeout value.
You are welcome to open a jira and attach a frame trace of the handshake and your broker configuration if you think there is a problem. -- Tim Bish Sr Software Engineer | RedHat Inc. [email protected] | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
