Hi Michael, There's a couple of basic Proton-c clients used by the qpid-dispatch-router project for testing that I know generate heartbeats:
https://github.com/apache/qpid-dispatch/blob/master/tests/test-receiver.c https://github.com/apache/qpid-dispatch/blob/master/tests/test-sender.c The simplest test would be to run test-receiver against the broker with PN_TRACE_FRM=1 set. For example, running test-receiver against the qdrouterd router listening on 127.0.0.1: $ PN_TRACE_FRM=1 test-receiver [0x2122230]: AMQP:FRAME: -> AMQP [0x2122230]: AMQP:FRAME:0 -> @open(16) [container-id="TestReceiver", hostname="127.0.0.1", channel-max=32767] [0x2122230]: AMQP:FRAME:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647] [0x2122230]: AMQP:FRAME:0 -> @attach(18) [name="MyReceiver", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test-address", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0x2122230]: AMQP:FRAME:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1000, drain=false] 2020-05-13 09:03:01.389827 -0400 SERVER (info) [C1] Accepted connection to 0.0.0.0:amqp from 127.0.0.1:53872 2020-05-13 09:03:01.390048 -0400 ROUTER (info) [C1] Connection Opened: dir=in host=127.0.0.1:53872 vhost= encrypted=no auth=no user=anonymous container_id=TestReceiver props= [0x2122230]: AMQP:FRAME: <- AMQP [0x2122230]: AMQP:FRAME:0 <- @open(16) [container-id="Standalone_8x1ySu6yFUXK9yX", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="1.13.0-SNAPSHOT", :"qd.conn-id"=1}] [0x2122230]: AMQP:FRAME:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647] 2020-05-13 09:03:01.390342 -0400 ROUTER_CORE (info) [C1][L6] Link attached: dir=out source={test-address expire:sess} target={<none> expire:sess} [0x2122230]: AMQP:FRAME:0 <- @attach(18) [name="MyReceiver", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test-address", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], target=@target(41) [durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) There's no messages available on the router, so the test-receiver is waiting for messages to arrive. At the bottom of the trace you see: [0x2122230]: AMQP:FRAME:0 -> (EMPTY FRAME) These are the heartbeat frames sent from test-receiver. test-receiver automatically generates these every 4 seconds because the router has advertised an idle-timeout=8000 (milliseconds) in it's open frame: [0x2122230]: AMQP:FRAME:0 <- @open(16) [container-id="Standalone_8x1ySu6yFUXK9yX", max-frame-size=16384, channel-max=32767, *idle-time-out=8000*, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="1.13.0-SNAPSHOT", :"qd.conn-id"=1}] Try test-receiver against rabbitmq - you should see the @open frame from rabbitmq advertise an idle-timeout of 60 seconds, and test-receiver send empty frames every 30 seconds (assuming no messages available). Note: by default test-receiver tries to read from a queue named "test-address", this can be changed using the "-s" option (see test-receiver -h". -K On Tue, May 12, 2020 at 5:40 AM Michael Ivanov <iv...@logit-ag.de> wrote: > Good morning, > > Sorry, we have just tested it with empty message senbt with 30s interval > and broker still closes the connection with timeout diagnostics. So it > seems it expects actual heartbeat. Is it possible to send heartbeat message > explicitly? > > Best regards, > > On 08.05.2020 21:14, Gordon Sim wrote: > > On 08/05/2020 3:57 pm, Michael Ivanov wrote: > >> I am using pn_messenger_t interface in my private select-based event > loop. > >> I use pn_selectable_t to trigger actual i/o. > >> > >> As far as I have seen in proton/c source pn_transport_tick is invoked > only > >> from pni_messenger_tick, which is in turn called from > pn_messenger_process > >> only. I do not call the latter explicitly and I do not invoke anything > >> to set any idle timeout interval inside pn_messenger. > >> > >> pn_transport_tick() just invokes function, pointed to by process_tick of > >> pn_io_layer_t structure: but I could not find where this field is set. > > > > Ok, I'm not sure if heartbeats have been thought through for the > messenger interface, particularly where you are driving the io > > yourself. > > > >> Can I use pn_message_t to send heartbeat explicitly? > > > > Heartbeats are only needed in the absence of other traffic, so if you > send messages frequently enough there is no need for > > heartbeats. > > > > I suspect there is no way of reading the idle-timeout advertised by the > broker through the messenger interface, but from the > > protocol trace it is 1 minute. So if you send messages more frequently > than that it will not disconnect you (in practice it is > > likely to wait double that timeout before giving up). > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > -- > \ / | | > (OvO) | Mikhail Iwanow | > (^^^) | Voice: +7 (911) 223-1300 | > \^/ | E-mail: iv...@logit-ag.de | > ^ ^ | | > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K
