You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Dirk Craeynest (JIRA)" <ji...@apache.org> on 2016/11/24 11:36:59 UTC
[jira] [Commented] (PROTON-1253) PHP client using C API send no
empty frames - ActiveMQ broker drops the connection due to Inactivity after
60 seconds
[ https://issues.apache.org/jira/browse/PROTON-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693042#comment-15693042 ]
Dirk Craeynest commented on PROTON-1253:
----------------------------------------
We're using the C API (in an Ada application), and would like to enable heartbeats as well, so are trying this patch.
With it we succeeded in getting heartbeats between a broker and a test program that plays the role of a "receiver" (i.e. doing pn_messenger_recv in a loop to "consume" messages sent to the broker). Setting the environment variable PN_TRACE_FRM=true we see empty frames being exchanged in both directions. So far, so good.
However, our application performs the "sender" role, i.e. it does a pn_messenger_send in a loop to send messages to the broker. And here we don't succeed in getting heartbeats sent.
In a test setup, we have a broker running with the idle_timeout set to 2 seconds. We set the same value in our application as well, so expect empty frames to be exchanged every second when there's no other "traffic". However, this doesn't happen.
Our test application code does the following calls (very simplified):
pn_messenger to construct a Messenger
pn_messenger_set_timeout to a value of 2 seconds
pn_messenger_set_outgoing_window to a value of 20
pn_messenger_set_idle_timeout to a value of 2 seconds (= operation provided by patch)
pn_messenger_start
in a loop:
if there's anything to send:
multiple calls to pn_messenger_put to put all messages in Messenger
pn_messenger_send with parameter n set to -1, i.e. block until all msgs sent or messenger timeout reached
otherwise:
delay for 5 seconds while accepting requests to stop
if no request to stop continue loop
after the loop:
pn_messenger_stop
We suspect the cause of the problem is that in between calls to pn_messenger_send, when there's nothing to send and no request to stop, our application is blocked in successive delays of 5 seconds. Presumably we need to make some Proton calls "in between" to allow the heartbeat frames to be sent? However, our searches through the QPID Proton tickets/forum/docs have not yet resulted in finding a solution.
Things we've tried are (among others):
- calling pn_messenger_process in between each of the 5 seconds delays (which doesn't work as that's longer than the idle_timeout);
- calling pn_messenger_work with a timeout of 5 seconds *instead* of the explicit 5 second delay (which didn't trigger heartbeats either).
We don't really understand how the Proton layer can send out these heartbeats "under the hood" unless when the application is blocked in a Proton operation (such as recv, see above) or by using a separate thread that manages all sending of messages.
We suspect we're overlooking something trivial, and appreciate any help or hints...
> PHP client using C API send no empty frames - ActiveMQ broker drops the connection due to Inactivity after 60 seconds
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: PROTON-1253
> URL: https://issues.apache.org/jira/browse/PROTON-1253
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.12.0, 0.13.0
> Environment: Linux yuriy-Aspire-E5-573G 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Yuriy Yakubskiy
> Labels: messenger, patch, php-proton
> Attachments: qpid-proton-0.13.0_messenger_set_idle_timeout_patch.tar.gz
>
>
> Dear developers,
> Could you please, clarify the following issue.
> PHP client disconnected after no data message in the queue for 60 seconds.
> Have client frame trace enabled (PN_TRACE_FRM=true)
> No active frame sent by the client in order to prevent being disconnected by ActiveMQ InactivityMonitor
> Please advice, is there any way of setting heartbeats for the PHP client.
> Please find, frames trace below.
> Kind Regards,
> Yuriy
> 2016-07-11 14:05:46
> [0x2af58f0]: -> AMQP
> [0x2af58f0]:0 -> @open(16) [container-id="68426F2E-012E-4A64-BE2E-1E5355B4B022", hostname="0.0.0.0", channel-max=32767]
> [0x2af58f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]
> [0x2af58f0]:0 -> @attach(18) [name="first-test-queue", handle=0, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="first-test-queue", durable=0, timeout=0, dynamic=false], target=@target(41) [address="first-test-queue", durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> [0x2af58f0]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1024, drain=false]
> [0x2af58f0]: <- AMQP
> [0x2af58f0]:0 <- @open(16) [container-id="", hostname="", max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], properties={:product="ActiveMQ", :platform="Java/1.7.0_101", :"topic-prefix"="topic://", :"queue-prefix"="queue://", :version="5.12.0"}]
> [0x2af58f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x2af58f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=1, outgoing-window=0]
> [0x2af58f0]:0 <- @attach(18) [name="first-test-queue", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="first-test-queue"], target=@target(41) [address="first-test-queue"], incomplete-unsettled=false, initial-delivery-count=0]
> [0x2af58f0]:0 <- @close(24) [error=@error(29) [condition=:"amqp:resource-limit-exceeded", description="local-idle-timeout expired"]]
> [0x2af58f0]: <- EOS
> [0x2af58f0]:0 -> @close(24) []
> [0x2af58f0]: -> EOS
> 2016-07-11 14:06:46
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org