Realised I missed covering a bit I meant to.. "Seems like i need to set the remote_idle_timeout to never time out, but how is this possible?"
It isn't. In this scenario, ServiceBus has decided what its requirements for idle behaviour are, and advertised a value in its Open frame (the remote idle timeout) to the client to prompt appropriate behaviour to satisfy them. If the client doesnt satisfy its needs, ServiceBus then closes the connection. When you set the idle-timeout configuration locally, thats basically the reverse case: the client telling ServiceBus what the clients needs are in its Open frame, and then if ServiceBus doesn't satisfy them then the client end will close the connection. In both cases, the client side mechanics are handled via the transport 'tick' process I mentioned earlier. Robbie On 5 October 2016 at 11:37, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > Setting the 'idle timeout' config will influence what is > advertised/requested in the Open frames sent to the peer, but that in > itself does not do the work needed to send heartbeat frames or enforce > that they haven't been received. There is a 'tick' method on the > transport that is responsible for doing that, and identifying the next > point it needs to be called to do any necessary work. The 'non > connection_engine' bits are likely doing that process for you. I don't > know if/how this was exposed in the 0.12.2 connection_engine stuff, > and it may have changed since, but that perhaps may give you some > place to look before folks with more of a clue on these bits are > around later. > > Questions like these would generally be better suited on the users@ > list, and certainly would be more visible there. > > Robbie > > On 5 October 2016 at 09:44, Tobias Duckworth <tob...@duckworth.uk.com> wrote: >> Hi, >> >> I'm experiencing the exact same problem using the connection_engine variant >> of qpid-proton (version 0.12.2) - The non connection_engine build does not >> exhibit the problem. >> >> I'd like to fix this, could you explain what's involved please? >> >> If I set the connection_option idle_timeout >> (proton::connection_options().idle_timeout(proton::duration::FOREVER)), I >> can see it come out in the output when I have PN_TRACE_FRM=1 : >> >> [0x2b3904003f30]:0 -> @open(16) >> [container-id="1104db2d-87ac-492f-89d2-0803dee95435", >> hostname="TWDIoTHub.azure-devices.net:5671", channel-max=32767, >> idle-time-out=2147483647] >> [0x2b3904003f30]: <- AMQP >> [0x2b3904003f30]:0 <- @open(16) >> [container-id="DeviceGateway_d56c48665111490aae2f99f08862d6b6", >> hostname="10.0.4.51", max-frame-size=65536, channel-max=8191, >> idle-time-out=240000] >> >> And if I trace out the transport idle timeouts I get: >> >> idle_timeout = 4294967295 >> remote_idle_timeout = 240000 >> >> Which seems to correlate. >> >> However, after 315 seconds I consistently get the following: >> >> [0x2b3904006300]:0 <- @close(24) [error=@error(29) >> [condition=:"amqp:connection:forced", description="The connection was >> inactive for more than the allowed period of time."]] >> >> Seems like i need to set the remote_idle_timeout to never time out, but how >> is this possible? >> >> Thanks, >> Toby >> >> >> >> -- >> View this message in context: >> http://qpid.2158936.n2.nabble.com/Azure-Service-Bus-receiver-timing-out-with-electron-go-binding-tp7651057p7651523.html >> Sent from the Apache Qpid developers mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
