You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Michael Ivanov <iv...@logit-ag.de> on 2020/03/03 09:56:43 UTC
proton and rabbitmq broker
Hallo,
Can proton library communicate with rabbitmq broker? I tried to use my existing
program to rabbitmq but would not even complete the subscription. Are there any
specifics about it?
Best regards,
--
\ / | |
(OvO) | Mikhail Iwanow |
(^^^) | Voice: +7 (911) 223-1300 |
\^/ | E-mail: ivans@logit-ag.de |
^ ^ | |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Ken Giusti <kg...@redhat.com>.
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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
>
> --
> \ / | |
> (OvO) | Mikhail Iwanow |
> (^^^) | Voice: +7 (911) 223-1300 |
> \^/ | E-mail: ivans@logit-ag.de |
> ^ ^ | |
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
On 12/05/2020 10:33 am, Michael Ivanov wrote:
> Sorry, we have just tested it with empty message senbt with 30s interval
> and broker still closes the connection with timeout diagnostics.
If that is the case, then the broker is not honouring the specification.
'Heartbeats' in AMQP 1.0 are simply empty frames. If there are actual
(non-empty) frames sent frequently enough there is no need to send empty
ones.
Are you sure the frames are actually sent on the wire at the required
frequency? If you can get a broker side trace showing that they are and
that the broker still disconnects, I would take that to the broker team
as a bug.
> So it
> seems it expects actual heartbeat. Is it possible to send heartbeat message
> explicitly?
No.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Michael Ivanov <iv...@logit-ag.de>.
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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
\ / | |
(OvO) | Mikhail Iwanow |
(^^^) | Voice: +7 (911) 223-1300 |
\^/ | E-mail: ivans@logit-ag.de |
^ ^ | |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Robbie Gemmell <ro...@gmail.com>.
On Fri, 8 May 2020 at 19:14, Gordon Sim <gs...@redhat.com> 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.
Probably not, heartbeat support was only added later originally I
think, plus Messenger was originally 'drives own IO' from my limited
recall. Other routes may have come later but probably not fully
considered as you say. More so given that lead to other bits being
created, with Messenger being deprecated years ago and removed from
the various bindings.
>
> > Can I use pn_message_t to send heartbeat explicitly?
>
No, heartbeats are entirely empty AMQP frames, not higher level empty
messages or empty message-transfer frames, so theres not an exposed
way to send them.
> 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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Michael Ivanov <iv...@isle.spb.ru>.
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.
Can I use pn_message_t to send heartbeat explicitly?
Best regards,
On 08.05.2020 17:28, Gordon Sim wrote:
> On 08/05/2020 3:04 pm, Michael Ivanov wrote:
>> I attached proton trace with FRM added. Short messages as below are my manual heartbeat messages, sent each 5 minutes:
>>
>> [0xbdb950]:0 -> @transfer(20) [handle=0, delivery-id=3, delivery-tag=b"\x03\x00\x00\x00\x00\x00\x00\x00", message-format=0,
>> settled=true] (61) "\x00SpE\x00Ss\xd0\x00\x00\x001\x00\x00\x00\x03@@\xa1)amqp://157.200.89.200:5672/BPM.FINNAIR.IN"
>>
>> At remote side we have the following error:
>>
>> 2020-05-08 13:54:23.896 [error] <0.10682.4> closing AMQP connection <0.10682.4> (10.42.0.1:1555 -> 10.42.0.78:5672):
>> missed heartbeats from client, timeout: runnings
>>
>> With corresponding message in proton trace file:
>>
>> CONNECTION ERROR connection aborted (remote)
>>
>> I cannot identify anything like heartbeat inn trace file. Do I miss sthing?
>
> No, there are no heartbeats sent. RabbitMQ is specifying an idle-timeout of 60000ms i.e. 1 minute, which is why your messages do
> not suffice. If you sent them more frequently that would work.
>
> Are you using the proactor for IO or do you have your own solution there? If the latter you need to call pn_transport_tick, I
> believe, to have heartbeats sent out. The return from that tells you when you must call it again.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | Тел.: +7(911) 223-1300 |
\^/ | E-mail: ivans@isle.spb.ru |
^ ^ | |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
On 08/05/2020 3:04 pm, Michael Ivanov wrote:
> I attached proton trace with FRM added. Short messages as below are my manual heartbeat messages, sent each 5 minutes:
>
> [0xbdb950]:0 -> @transfer(20) [handle=0, delivery-id=3, delivery-tag=b"\x03\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true] (61) "\x00SpE\x00Ss\xd0\x00\x00\x001\x00\x00\x00\x03@@\xa1)amqp://157.200.89.200:5672/BPM.FINNAIR.IN"
>
> At remote side we have the following error:
>
> 2020-05-08 13:54:23.896 [error] <0.10682.4> closing AMQP connection <0.10682.4> (10.42.0.1:1555 -> 10.42.0.78:5672):
> missed heartbeats from client, timeout: runnings
>
> With corresponding message in proton trace file:
>
> CONNECTION ERROR connection aborted (remote)
>
> I cannot identify anything like heartbeat inn trace file. Do I miss sthing?
No, there are no heartbeats sent. RabbitMQ is specifying an idle-timeout
of 60000ms i.e. 1 minute, which is why your messages do not suffice. If
you sent them more frequently that would work.
Are you using the proactor for IO or do you have your own solution
there? If the latter you need to call pn_transport_tick, I believe, to
have heartbeats sent out. The return from that tells you when you must
call it again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Michael Ivanov <iv...@isle.spb.ru>.
I attached proton trace with FRM added. Short messages as below are my manual heartbeat messages, sent each 5 minutes:
[0xbdb950]:0 -> @transfer(20) [handle=0, delivery-id=3, delivery-tag=b"\x03\x00\x00\x00\x00\x00\x00\x00", message-format=0,
settled=true] (61) "\x00SpE\x00Ss\xd0\x00\x00\x001\x00\x00\x00\x03@@\xa1)amqp://157.200.89.200:5672/BPM.FINNAIR.IN"
At remote side we have the following error:
2020-05-08 13:54:23.896 [error] <0.10682.4> closing AMQP connection <0.10682.4> (10.42.0.1:1555 -> 10.42.0.78:5672):
missed heartbeats from client, timeout: runnings
With corresponding message in proton trace file:
CONNECTION ERROR connection aborted (remote)
I cannot identify anything like heartbeat inn trace file. Do I miss sthing?
Best regards,
On 08.05.2020 15:57, Gordon Sim wrote:
> On 08/05/2020 1:40 pm, Michael Ivanov wrote:
>> Will setting of PN_TRACE_RAW, PN_TRACE_FRM, PN_TRACE_DRV or PN_TRACE_EVT be useful?
>
> PN_TRACE_FRM is the one that shows all the protocol frames
>
>> What kind of frames are expected to be observed in tcpdump trace fpor heartbeats?
>
> They show as 'EMPTY FRAME'. The @open frame from the broker is also relevant as that is where the idle time out the broker is
> using is specified.
>
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | Тел.: +7(911) 223-1300 |
\^/ | E-mail: ivans@isle.spb.ru |
^ ^ | |
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
On 08/05/2020 1:40 pm, Michael Ivanov wrote:
> Will setting of PN_TRACE_RAW, PN_TRACE_FRM, PN_TRACE_DRV or PN_TRACE_EVT be useful?
PN_TRACE_FRM is the one that shows all the protocol frames
> What kind of frames are expected to be observed in tcpdump trace fpor heartbeats?
They show as 'EMPTY FRAME'. The @open frame from the broker is also
relevant as that is where the idle time out the broker is using is
specified.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Michael Ivanov <iv...@isle.spb.ru>.
That's what I can see with PN_TRACE_LOG on:
730D944B-C31E-4558-B672-35731B5AD132: delaying
730D944B-C31E-4558-B672-35731B5AD132: let's drain
730D944B-C31E-4558-B672-35731B5AD132: delaying
CONNECTION ERROR connection aborted (remote)
730D944B-C31E-4558-B672-35731B5AD132: let's drain
730D944B-C31E-4558-B672-35731B5AD132: delaying
730D944B-C31E-4558-B672-35731B5AD132: let's drain
. . . . . .
730D944B-C31E-4558-B672-35731B5AD132: let's drain
730D944B-C31E-4558-B672-35731B5AD132: let's drain
730D944B-C31E-4558-B672-35731B5AD132: initializing next_drain
connection created: 0xc70e50
730D944B-C31E-4558-B672-35731B5AD132: let's drain
session created: 0xc85ac0
730D944B-C31E-4558-B672-35731B5AD132: let's drain
730D944B-C31E-4558-B672-35731B5AD132: initializing next_drain
link created: 0xc73d60
730D944B-C31E-4558-B672-35731B5AD132: let's drain
730D944B-C31E-4558-B672-35731B5AD132: delaying
730D944B-C31E-4558-B672-35731B5AD132: let's drain
CONNECTION ERROR connection aborted (remote) is evidently occurred when rabbitmq closed
the connection due to missing heartbeat.
Will setting of PN_TRACE_RAW, PN_TRACE_FRM, PN_TRACE_DRV or PN_TRACE_EVT be useful?
What kind of frames are expected to be observed in tcpdump trace fpor heartbeats?
Currently I see only messages that are explicitly sent.
Best regards,
On 08.05.2020 14:04, Gordon Sim wrote:
> On 08/05/2020 11:45 am, Michael Ivanov wrote:
>> No, this should not be the case. I am sending messages from select-based event loop
>> using pn_selectable_t objects.
>
> Are you able to get a protocol trace for a disconnected connection?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | Тел.: +7(911) 223-1300 |
\^/ | E-mail: ivans@isle.spb.ru |
^ ^ | |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
On 08/05/2020 11:45 am, Michael Ivanov wrote:
> No, this should not be the case. I am sending messages from select-based event loop
> using pn_selectable_t objects.
Are you able to get a protocol trace for a disconnected connection?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Michael Ivanov <iv...@isle.spb.ru>.
No, this should not be the case. I am sending messages from select-based event loop
using pn_selectable_t objects.
On 08.05.2020 13:41, Gordon Sim wrote:
> On 08/05/2020 10:44 am, Michael Ivanov wrote:
>> When sending messages to rabbitmq broker, tha latter periodically closes the connection
>> with following diagnostics:
>>
>> missed heartbeats from client, timeout: runnings
>>
>> I tried to send empty amqp messages but this did not help. How do I send the
>> heartbeat it requests?
>
> The client should send the heartbeats automatically. Are you perhaps blocking the event processing in the client library?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
\ / | |
(OvO) | Михаил Иванов |
(^^^) | Тел.: +7(911) 223-1300 |
\^/ | E-mail: ivans@isle.spb.ru |
^ ^ | |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
On 08/05/2020 10:44 am, Michael Ivanov wrote:
> When sending messages to rabbitmq broker, tha latter periodically closes the connection
> with following diagnostics:
>
> missed heartbeats from client, timeout: runnings
>
> I tried to send empty amqp messages but this did not help. How do I send the
> heartbeat it requests?
The client should send the heartbeats automatically. Are you perhaps
blocking the event processing in the client library?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Michael Ivanov <iv...@logit-ag.de>.
Hallo,
When sending messages to rabbitmq broker, tha latter periodically closes the connection
with following diagnostics:
missed heartbeats from client, timeout: runnings
I tried to send empty amqp messages but this did not help. How do I send the
heartbeat it requests?
Best regards,
On 03.03.2020 13:42, Robbie Gemmell wrote:
> On Tue, 3 Mar 2020 at 10:11, Gordon Sim <gs...@redhat.com> wrote:
>>
>> On 03/03/2020 9:56 am, Michael Ivanov wrote:
>>> Hallo,
>>>
>>> Can proton library communicate with rabbitmq broker? I tried to use my existing
>>> program to rabbitmq but would not even complete the subscription. Are there any
>>> specifics about it?
>>
>> You need to ensure the AMQP 1.0 plugin is enabled for RabbitMQ (the
>> default is a RabbitMQ variant of 0.9.1).
>>
>> If it is then turn on protocol tracing on the proton client for more
>> insight, with env var PN_TRACE_FRM=1.
>>
>
> There are also details of the brokers plugin at
> https://github.com/rabbitmq/rabbitmq-amqp1.0 such as particular
> mappings it does, naming conventions etc you might need to consider.
>
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
--
\ / | |
(OvO) | Mikhail Iwanow |
(^^^) | Voice: +7 (911) 223-1300 |
\^/ | E-mail: ivans@logit-ag.de |
^ ^ | |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 3 Mar 2020 at 10:11, Gordon Sim <gs...@redhat.com> wrote:
>
> On 03/03/2020 9:56 am, Michael Ivanov wrote:
> > Hallo,
> >
> > Can proton library communicate with rabbitmq broker? I tried to use my existing
> > program to rabbitmq but would not even complete the subscription. Are there any
> > specifics about it?
>
> You need to ensure the AMQP 1.0 plugin is enabled for RabbitMQ (the
> default is a RabbitMQ variant of 0.9.1).
>
> If it is then turn on protocol tracing on the proton client for more
> insight, with env var PN_TRACE_FRM=1.
>
There are also details of the brokers plugin at
https://github.com/rabbitmq/rabbitmq-amqp1.0 such as particular
mappings it does, naming conventions etc you might need to consider.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: proton and rabbitmq broker
Posted by Gordon Sim <gs...@redhat.com>.
On 03/03/2020 9:56 am, Michael Ivanov wrote:
> Hallo,
>
> Can proton library communicate with rabbitmq broker? I tried to use my existing
> program to rabbitmq but would not even complete the subscription. Are there any
> specifics about it?
You need to ensure the AMQP 1.0 plugin is enabled for RabbitMQ (the
default is a RabbitMQ variant of 0.9.1).
If it is then turn on protocol tracing on the proton client for more
insight, with env var PN_TRACE_FRM=1.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org