You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Adrian Florea <fl...@gmail.com> on 2020/06/17 17:04:14 UTC
Qpid proton c -- pn_message_send
Hi,
Any idea is welcome on this one.
I am trying to send messages (via a sender link) at various moments in the
life of a program. I am using pn_message_send.
I have set the outgoing window size to 1, on the session.
The current behavior is:
1. pn_message_send completes OK
2. nothing is actually sent
3. after a while (I guess this is where I miss something) I see that the
proactor gets an event of type PN_TRANSPORT and I can see all messages
being really sent.
Is there a way to achieve a "send immediate" behavior ?
When a message send is invoked, I need it to really go out.
many thanks for pointing me in the right direction,
Adrian
Re: Qpid proton c -- pn_message_send
Posted by Gordon Sim <gs...@redhat.com>.
On 17/06/2020 6:04 pm, Adrian Florea wrote:
> Hi,
>
> Any idea is welcome on this one.
>
> I am trying to send messages (via a sender link) at various moments in the
> life of a program. I am using pn_message_send.
>
> I have set the outgoing window size to 1, on the session.
>
> The current behavior is:
>
> 1. pn_message_send completes OK
> 2. nothing is actually sent
> 3. after a while (I guess this is where I miss something) I see that the
> proactor gets an event of type PN_TRANSPORT and I can see all messages
> being really sent.
>
> Is there a way to achieve a "send immediate" behavior ?
>
> When a message send is invoked, I need it to really go out.
>
> many thanks for pointing me in the right direction,
The proton api is an event based one. The pn_message_send call is
asynchronous. You need to ensure the eventloop has the thread of control
for it to be able to act on the request to send.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
Finally :)
I managed to integrate the proactor in my program loop by using
pn_proactor_get carefully correlated with pn_proactor_done.
The main mistake I did, was that I used to call pn_proactor_done after
getting a flow event and just before calling send.
Many thanks for advise and for patience.
Adrian
On Thu, Jun 18, 2020, 7:50 AM Adrian Florea <fl...@gmail.com> wrote:
> OK, so it must be pn_proactor_wait() or can I achieve similar behavior
> with pn_proactor_get() ? I assume not.
>
> It would be nice if pn_proactor_wait would have a timed_wait option.
>
>
>
> On Thu, Jun 18, 2020, 7:44 AM Ted Ross <tr...@redhat.com> wrote:
>
>> If you look at the examples supplied with Proton, you will see simple
>> applications that behave as you desire. Sends are immediate.
>>
>> Changing your idle timeout is only altering the timing of the bad behavior
>> of your app. You need to find a way to incorporate pn_proactor_wait into
>> your logic.
>>
>> On Thu, Jun 18, 2020 at 1:07 AM Adrian Florea <fl...@gmail.com>
>> wrote:
>>
>> > So, based on this email chain and looking at what the idle timeout is
>> > intended for, I think that is true ... proton is "woke up" by these
>> > heartbeats, like you said. Playing with transport timeout values, just
>> > increased their frequency.
>> >
>> > I will look at other possibilities to obtain an "immediate send" effect.
>> >
>> >
>> > On Wed, Jun 17, 2020, 3:26 PM Adrian Florea <fl...@gmail.com>
>> wrote:
>> >
>> > > Some news.
>> > >
>> > > After setting up the transport (SSL and all), I added a call to
>> > > pn_transport_set_idle_timeout, with 20000ms.
>> > >
>> > > This provides great improvement, as now I can see my messages going
>> out
>> > > every few seconds, definitely sooner than 20s.
>> > >
>> > > As a side note, I tried to set the timeout to a subsecond value,
>> doesn't
>> > > work.
>> > > Said it must be min 10000. Setting it to 10000 is causing a subsequent
>> > > error with the connection timeout. The connection timeout becomes 5000
>> > ...
>> > > so I ended up setting transport timeout to 20000 to achieve a
>> cinnection
>> > > timeout of 10000.
>> > >
>> > > As I said, this provides great improvement but it would be nice if the
>> > > send can be "flushed" immediately.
>> > >
>> > > Adrian
>> > >
>> > > On Wed, Jun 17, 2020, 2:40 PM Ted Ross <tr...@redhat.com> wrote:
>> > >
>> > >> Proactor is a single-threaded, event-driven API for messaging. It
>> owns
>> > >> the
>> > >> main execution loop and uses the pn_proactor_wait() execution to do
>> > >> background work like sending your message out the connection.
>> > >>
>> > >> I don't know what your application looks like, but I assume that you
>> > have
>> > >> your own main loop and you don't ever give proactor a chance to run.
>> > Your
>> > >> message is probably being sent when a heartbeat frame arrives from
>> > >> whatever
>> > >> you're connected to. This is the PN_TRANSPORT event you are seeing.
>> > >>
>> > >> -Ted
>> > >>
>> > >> On Wed, Jun 17, 2020 at 3:00 PM Adrian Florea <fl...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > Yeah... forget my last mention. Looking at what pn_proactor_done
>> does,
>> > >> it
>> > >> > doesn't make sense to call it when the batch of events is null.
>> > >> >
>> > >> > On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com>
>> > >> wrote:
>> > >> >
>> > >> > > Yes.
>> > >> > > I don't call it when the pn_proactor_get() returns null.
>> > >> > >
>> > >> > > I should probably call it in this case as well..
>> > >> > >
>> > >> > >
>> > >> > > On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
>> > >> > >
>> > >> > >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <
>> > florea.adi@gmail.com>
>> > >> > >> wrote:
>> > >> > >>
>> > >> > >> > Hi, thanks.
>> > >> > >> > I am using the proactor.
>> > >> > >> > I need a way to clearly send a message out.
>> > >> > >> > My program has a loop and everytime it loops, I tried this:
>> > >> > >> >
>> > >> > >> > - call pn_proactor_wait --> this ends up blocking my loop,
>> which
>> > >> is
>> > >> > not
>> > >> > >> > good.
>> > >> > >> >
>> > >> > >> > - call pn_proactor_get -- this does not block and returns no
>> > event
>> > >> > for a
>> > >> > >> > long while, when suddenly it gets a PN_TRANSPORT event and
>> all my
>> > >> > >> messages
>> > >> > >> > are really sent out.
>> > >> > >> >
>> > >> > >>
>> > >> > >> Are you calling pn_proactor_done() after processing the batch of
>> > >> events
>> > >> > >> from pn_proactor_get()?
>> > >> > >>
>> > >> > >>
>> > >> > >> >
>> > >> > >> > Adrian
>> > >> > >> >
>> > >> > >> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com>
>> > wrote:
>> > >> > >> >
>> > >> > >> > > Hi Adrian,
>> > >> > >> > >
>> > >> > >> > > What is your program doing after it calls pn_message_send?
>> > That
>> > >> > >> function
>> > >> > >> > > queues the message for delivery but the delivery isn't
>> actually
>> > >> > >> > transferred
>> > >> > >> > > until the application yields the control back to the Proton
>> > >> reactor
>> > >> > >> (via
>> > >> > >> > > pn_proactor_wait). If the application is doing other
>> > processing
>> > >> or
>> > >> > >> > waiting
>> > >> > >> > > on a condition or mutex, the delivery won't go out the door
>> > >> > >> immediately.
>> > >> > >> > >
>> > >> > >> > > -Ted
>> > >> > >> > >
>> > >> > >> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <
>> > >> florea.adi@gmail.com
>> > >> > >
>> > >> > >> > > wrote:
>> > >> > >> > >
>> > >> > >> > > > Hi,
>> > >> > >> > > >
>> > >> > >> > > > Any idea is welcome on this one.
>> > >> > >> > > >
>> > >> > >> > > > I am trying to send messages (via a sender link) at
>> various
>> > >> > moments
>> > >> > >> in
>> > >> > >> > > the
>> > >> > >> > > > life of a program. I am using pn_message_send.
>> > >> > >> > > >
>> > >> > >> > > > I have set the outgoing window size to 1, on the session.
>> > >> > >> > > >
>> > >> > >> > > > The current behavior is:
>> > >> > >> > > >
>> > >> > >> > > > 1. pn_message_send completes OK
>> > >> > >> > > > 2. nothing is actually sent
>> > >> > >> > > > 3. after a while (I guess this is where I miss something)
>> I
>> > see
>> > >> > that
>> > >> > >> > the
>> > >> > >> > > > proactor gets an event of type PN_TRANSPORT and I can see
>> all
>> > >> > >> messages
>> > >> > >> > > > being really sent.
>> > >> > >> > > >
>> > >> > >> > > > Is there a way to achieve a "send immediate" behavior ?
>> > >> > >> > > >
>> > >> > >> > > > When a message send is invoked, I need it to really go
>> out.
>> > >> > >> > > >
>> > >> > >> > > > many thanks for pointing me in the right direction,
>> > >> > >> > > >
>> > >> > >> > > > Adrian
>> > >> > >> > > >
>> > >> > >> > >
>> > >> > >> >
>> > >> > >>
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
OK, so it must be pn_proactor_wait() or can I achieve similar behavior with
pn_proactor_get() ? I assume not.
It would be nice if pn_proactor_wait would have a timed_wait option.
On Thu, Jun 18, 2020, 7:44 AM Ted Ross <tr...@redhat.com> wrote:
> If you look at the examples supplied with Proton, you will see simple
> applications that behave as you desire. Sends are immediate.
>
> Changing your idle timeout is only altering the timing of the bad behavior
> of your app. You need to find a way to incorporate pn_proactor_wait into
> your logic.
>
> On Thu, Jun 18, 2020 at 1:07 AM Adrian Florea <fl...@gmail.com>
> wrote:
>
> > So, based on this email chain and looking at what the idle timeout is
> > intended for, I think that is true ... proton is "woke up" by these
> > heartbeats, like you said. Playing with transport timeout values, just
> > increased their frequency.
> >
> > I will look at other possibilities to obtain an "immediate send" effect.
> >
> >
> > On Wed, Jun 17, 2020, 3:26 PM Adrian Florea <fl...@gmail.com>
> wrote:
> >
> > > Some news.
> > >
> > > After setting up the transport (SSL and all), I added a call to
> > > pn_transport_set_idle_timeout, with 20000ms.
> > >
> > > This provides great improvement, as now I can see my messages going out
> > > every few seconds, definitely sooner than 20s.
> > >
> > > As a side note, I tried to set the timeout to a subsecond value,
> doesn't
> > > work.
> > > Said it must be min 10000. Setting it to 10000 is causing a subsequent
> > > error with the connection timeout. The connection timeout becomes 5000
> > ...
> > > so I ended up setting transport timeout to 20000 to achieve a
> cinnection
> > > timeout of 10000.
> > >
> > > As I said, this provides great improvement but it would be nice if the
> > > send can be "flushed" immediately.
> > >
> > > Adrian
> > >
> > > On Wed, Jun 17, 2020, 2:40 PM Ted Ross <tr...@redhat.com> wrote:
> > >
> > >> Proactor is a single-threaded, event-driven API for messaging. It
> owns
> > >> the
> > >> main execution loop and uses the pn_proactor_wait() execution to do
> > >> background work like sending your message out the connection.
> > >>
> > >> I don't know what your application looks like, but I assume that you
> > have
> > >> your own main loop and you don't ever give proactor a chance to run.
> > Your
> > >> message is probably being sent when a heartbeat frame arrives from
> > >> whatever
> > >> you're connected to. This is the PN_TRANSPORT event you are seeing.
> > >>
> > >> -Ted
> > >>
> > >> On Wed, Jun 17, 2020 at 3:00 PM Adrian Florea <fl...@gmail.com>
> > >> wrote:
> > >>
> > >> > Yeah... forget my last mention. Looking at what pn_proactor_done
> does,
> > >> it
> > >> > doesn't make sense to call it when the batch of events is null.
> > >> >
> > >> > On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com>
> > >> wrote:
> > >> >
> > >> > > Yes.
> > >> > > I don't call it when the pn_proactor_get() returns null.
> > >> > >
> > >> > > I should probably call it in this case as well..
> > >> > >
> > >> > >
> > >> > > On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
> > >> > >
> > >> > >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <
> > florea.adi@gmail.com>
> > >> > >> wrote:
> > >> > >>
> > >> > >> > Hi, thanks.
> > >> > >> > I am using the proactor.
> > >> > >> > I need a way to clearly send a message out.
> > >> > >> > My program has a loop and everytime it loops, I tried this:
> > >> > >> >
> > >> > >> > - call pn_proactor_wait --> this ends up blocking my loop,
> which
> > >> is
> > >> > not
> > >> > >> > good.
> > >> > >> >
> > >> > >> > - call pn_proactor_get -- this does not block and returns no
> > event
> > >> > for a
> > >> > >> > long while, when suddenly it gets a PN_TRANSPORT event and all
> my
> > >> > >> messages
> > >> > >> > are really sent out.
> > >> > >> >
> > >> > >>
> > >> > >> Are you calling pn_proactor_done() after processing the batch of
> > >> events
> > >> > >> from pn_proactor_get()?
> > >> > >>
> > >> > >>
> > >> > >> >
> > >> > >> > Adrian
> > >> > >> >
> > >> > >> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com>
> > wrote:
> > >> > >> >
> > >> > >> > > Hi Adrian,
> > >> > >> > >
> > >> > >> > > What is your program doing after it calls pn_message_send?
> > That
> > >> > >> function
> > >> > >> > > queues the message for delivery but the delivery isn't
> actually
> > >> > >> > transferred
> > >> > >> > > until the application yields the control back to the Proton
> > >> reactor
> > >> > >> (via
> > >> > >> > > pn_proactor_wait). If the application is doing other
> > processing
> > >> or
> > >> > >> > waiting
> > >> > >> > > on a condition or mutex, the delivery won't go out the door
> > >> > >> immediately.
> > >> > >> > >
> > >> > >> > > -Ted
> > >> > >> > >
> > >> > >> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <
> > >> florea.adi@gmail.com
> > >> > >
> > >> > >> > > wrote:
> > >> > >> > >
> > >> > >> > > > Hi,
> > >> > >> > > >
> > >> > >> > > > Any idea is welcome on this one.
> > >> > >> > > >
> > >> > >> > > > I am trying to send messages (via a sender link) at various
> > >> > moments
> > >> > >> in
> > >> > >> > > the
> > >> > >> > > > life of a program. I am using pn_message_send.
> > >> > >> > > >
> > >> > >> > > > I have set the outgoing window size to 1, on the session.
> > >> > >> > > >
> > >> > >> > > > The current behavior is:
> > >> > >> > > >
> > >> > >> > > > 1. pn_message_send completes OK
> > >> > >> > > > 2. nothing is actually sent
> > >> > >> > > > 3. after a while (I guess this is where I miss something) I
> > see
> > >> > that
> > >> > >> > the
> > >> > >> > > > proactor gets an event of type PN_TRANSPORT and I can see
> all
> > >> > >> messages
> > >> > >> > > > being really sent.
> > >> > >> > > >
> > >> > >> > > > Is there a way to achieve a "send immediate" behavior ?
> > >> > >> > > >
> > >> > >> > > > When a message send is invoked, I need it to really go out.
> > >> > >> > > >
> > >> > >> > > > many thanks for pointing me in the right direction,
> > >> > >> > > >
> > >> > >> > > > Adrian
> > >> > >> > > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Ted Ross <tr...@redhat.com>.
If you look at the examples supplied with Proton, you will see simple
applications that behave as you desire. Sends are immediate.
Changing your idle timeout is only altering the timing of the bad behavior
of your app. You need to find a way to incorporate pn_proactor_wait into
your logic.
On Thu, Jun 18, 2020 at 1:07 AM Adrian Florea <fl...@gmail.com> wrote:
> So, based on this email chain and looking at what the idle timeout is
> intended for, I think that is true ... proton is "woke up" by these
> heartbeats, like you said. Playing with transport timeout values, just
> increased their frequency.
>
> I will look at other possibilities to obtain an "immediate send" effect.
>
>
> On Wed, Jun 17, 2020, 3:26 PM Adrian Florea <fl...@gmail.com> wrote:
>
> > Some news.
> >
> > After setting up the transport (SSL and all), I added a call to
> > pn_transport_set_idle_timeout, with 20000ms.
> >
> > This provides great improvement, as now I can see my messages going out
> > every few seconds, definitely sooner than 20s.
> >
> > As a side note, I tried to set the timeout to a subsecond value, doesn't
> > work.
> > Said it must be min 10000. Setting it to 10000 is causing a subsequent
> > error with the connection timeout. The connection timeout becomes 5000
> ...
> > so I ended up setting transport timeout to 20000 to achieve a cinnection
> > timeout of 10000.
> >
> > As I said, this provides great improvement but it would be nice if the
> > send can be "flushed" immediately.
> >
> > Adrian
> >
> > On Wed, Jun 17, 2020, 2:40 PM Ted Ross <tr...@redhat.com> wrote:
> >
> >> Proactor is a single-threaded, event-driven API for messaging. It owns
> >> the
> >> main execution loop and uses the pn_proactor_wait() execution to do
> >> background work like sending your message out the connection.
> >>
> >> I don't know what your application looks like, but I assume that you
> have
> >> your own main loop and you don't ever give proactor a chance to run.
> Your
> >> message is probably being sent when a heartbeat frame arrives from
> >> whatever
> >> you're connected to. This is the PN_TRANSPORT event you are seeing.
> >>
> >> -Ted
> >>
> >> On Wed, Jun 17, 2020 at 3:00 PM Adrian Florea <fl...@gmail.com>
> >> wrote:
> >>
> >> > Yeah... forget my last mention. Looking at what pn_proactor_done does,
> >> it
> >> > doesn't make sense to call it when the batch of events is null.
> >> >
> >> > On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com>
> >> wrote:
> >> >
> >> > > Yes.
> >> > > I don't call it when the pn_proactor_get() returns null.
> >> > >
> >> > > I should probably call it in this case as well..
> >> > >
> >> > >
> >> > > On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
> >> > >
> >> > >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <
> florea.adi@gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >> > Hi, thanks.
> >> > >> > I am using the proactor.
> >> > >> > I need a way to clearly send a message out.
> >> > >> > My program has a loop and everytime it loops, I tried this:
> >> > >> >
> >> > >> > - call pn_proactor_wait --> this ends up blocking my loop, which
> >> is
> >> > not
> >> > >> > good.
> >> > >> >
> >> > >> > - call pn_proactor_get -- this does not block and returns no
> event
> >> > for a
> >> > >> > long while, when suddenly it gets a PN_TRANSPORT event and all my
> >> > >> messages
> >> > >> > are really sent out.
> >> > >> >
> >> > >>
> >> > >> Are you calling pn_proactor_done() after processing the batch of
> >> events
> >> > >> from pn_proactor_get()?
> >> > >>
> >> > >>
> >> > >> >
> >> > >> > Adrian
> >> > >> >
> >> > >> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com>
> wrote:
> >> > >> >
> >> > >> > > Hi Adrian,
> >> > >> > >
> >> > >> > > What is your program doing after it calls pn_message_send?
> That
> >> > >> function
> >> > >> > > queues the message for delivery but the delivery isn't actually
> >> > >> > transferred
> >> > >> > > until the application yields the control back to the Proton
> >> reactor
> >> > >> (via
> >> > >> > > pn_proactor_wait). If the application is doing other
> processing
> >> or
> >> > >> > waiting
> >> > >> > > on a condition or mutex, the delivery won't go out the door
> >> > >> immediately.
> >> > >> > >
> >> > >> > > -Ted
> >> > >> > >
> >> > >> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <
> >> florea.adi@gmail.com
> >> > >
> >> > >> > > wrote:
> >> > >> > >
> >> > >> > > > Hi,
> >> > >> > > >
> >> > >> > > > Any idea is welcome on this one.
> >> > >> > > >
> >> > >> > > > I am trying to send messages (via a sender link) at various
> >> > moments
> >> > >> in
> >> > >> > > the
> >> > >> > > > life of a program. I am using pn_message_send.
> >> > >> > > >
> >> > >> > > > I have set the outgoing window size to 1, on the session.
> >> > >> > > >
> >> > >> > > > The current behavior is:
> >> > >> > > >
> >> > >> > > > 1. pn_message_send completes OK
> >> > >> > > > 2. nothing is actually sent
> >> > >> > > > 3. after a while (I guess this is where I miss something) I
> see
> >> > that
> >> > >> > the
> >> > >> > > > proactor gets an event of type PN_TRANSPORT and I can see all
> >> > >> messages
> >> > >> > > > being really sent.
> >> > >> > > >
> >> > >> > > > Is there a way to achieve a "send immediate" behavior ?
> >> > >> > > >
> >> > >> > > > When a message send is invoked, I need it to really go out.
> >> > >> > > >
> >> > >> > > > many thanks for pointing me in the right direction,
> >> > >> > > >
> >> > >> > > > Adrian
> >> > >> > > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
So, based on this email chain and looking at what the idle timeout is
intended for, I think that is true ... proton is "woke up" by these
heartbeats, like you said. Playing with transport timeout values, just
increased their frequency.
I will look at other possibilities to obtain an "immediate send" effect.
On Wed, Jun 17, 2020, 3:26 PM Adrian Florea <fl...@gmail.com> wrote:
> Some news.
>
> After setting up the transport (SSL and all), I added a call to
> pn_transport_set_idle_timeout, with 20000ms.
>
> This provides great improvement, as now I can see my messages going out
> every few seconds, definitely sooner than 20s.
>
> As a side note, I tried to set the timeout to a subsecond value, doesn't
> work.
> Said it must be min 10000. Setting it to 10000 is causing a subsequent
> error with the connection timeout. The connection timeout becomes 5000 ...
> so I ended up setting transport timeout to 20000 to achieve a cinnection
> timeout of 10000.
>
> As I said, this provides great improvement but it would be nice if the
> send can be "flushed" immediately.
>
> Adrian
>
> On Wed, Jun 17, 2020, 2:40 PM Ted Ross <tr...@redhat.com> wrote:
>
>> Proactor is a single-threaded, event-driven API for messaging. It owns
>> the
>> main execution loop and uses the pn_proactor_wait() execution to do
>> background work like sending your message out the connection.
>>
>> I don't know what your application looks like, but I assume that you have
>> your own main loop and you don't ever give proactor a chance to run. Your
>> message is probably being sent when a heartbeat frame arrives from
>> whatever
>> you're connected to. This is the PN_TRANSPORT event you are seeing.
>>
>> -Ted
>>
>> On Wed, Jun 17, 2020 at 3:00 PM Adrian Florea <fl...@gmail.com>
>> wrote:
>>
>> > Yeah... forget my last mention. Looking at what pn_proactor_done does,
>> it
>> > doesn't make sense to call it when the batch of events is null.
>> >
>> > On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com>
>> wrote:
>> >
>> > > Yes.
>> > > I don't call it when the pn_proactor_get() returns null.
>> > >
>> > > I should probably call it in this case as well..
>> > >
>> > >
>> > > On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
>> > >
>> > >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <fl...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > Hi, thanks.
>> > >> > I am using the proactor.
>> > >> > I need a way to clearly send a message out.
>> > >> > My program has a loop and everytime it loops, I tried this:
>> > >> >
>> > >> > - call pn_proactor_wait --> this ends up blocking my loop, which
>> is
>> > not
>> > >> > good.
>> > >> >
>> > >> > - call pn_proactor_get -- this does not block and returns no event
>> > for a
>> > >> > long while, when suddenly it gets a PN_TRANSPORT event and all my
>> > >> messages
>> > >> > are really sent out.
>> > >> >
>> > >>
>> > >> Are you calling pn_proactor_done() after processing the batch of
>> events
>> > >> from pn_proactor_get()?
>> > >>
>> > >>
>> > >> >
>> > >> > Adrian
>> > >> >
>> > >> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
>> > >> >
>> > >> > > Hi Adrian,
>> > >> > >
>> > >> > > What is your program doing after it calls pn_message_send? That
>> > >> function
>> > >> > > queues the message for delivery but the delivery isn't actually
>> > >> > transferred
>> > >> > > until the application yields the control back to the Proton
>> reactor
>> > >> (via
>> > >> > > pn_proactor_wait). If the application is doing other processing
>> or
>> > >> > waiting
>> > >> > > on a condition or mutex, the delivery won't go out the door
>> > >> immediately.
>> > >> > >
>> > >> > > -Ted
>> > >> > >
>> > >> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <
>> florea.adi@gmail.com
>> > >
>> > >> > > wrote:
>> > >> > >
>> > >> > > > Hi,
>> > >> > > >
>> > >> > > > Any idea is welcome on this one.
>> > >> > > >
>> > >> > > > I am trying to send messages (via a sender link) at various
>> > moments
>> > >> in
>> > >> > > the
>> > >> > > > life of a program. I am using pn_message_send.
>> > >> > > >
>> > >> > > > I have set the outgoing window size to 1, on the session.
>> > >> > > >
>> > >> > > > The current behavior is:
>> > >> > > >
>> > >> > > > 1. pn_message_send completes OK
>> > >> > > > 2. nothing is actually sent
>> > >> > > > 3. after a while (I guess this is where I miss something) I see
>> > that
>> > >> > the
>> > >> > > > proactor gets an event of type PN_TRANSPORT and I can see all
>> > >> messages
>> > >> > > > being really sent.
>> > >> > > >
>> > >> > > > Is there a way to achieve a "send immediate" behavior ?
>> > >> > > >
>> > >> > > > When a message send is invoked, I need it to really go out.
>> > >> > > >
>> > >> > > > many thanks for pointing me in the right direction,
>> > >> > > >
>> > >> > > > Adrian
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
Some news.
After setting up the transport (SSL and all), I added a call to
pn_transport_set_idle_timeout, with 20000ms.
This provides great improvement, as now I can see my messages going out
every few seconds, definitely sooner than 20s.
As a side note, I tried to set the timeout to a subsecond value, doesn't
work.
Said it must be min 10000. Setting it to 10000 is causing a subsequent
error with the connection timeout. The connection timeout becomes 5000 ...
so I ended up setting transport timeout to 20000 to achieve a cinnection
timeout of 10000.
As I said, this provides great improvement but it would be nice if the send
can be "flushed" immediately.
Adrian
On Wed, Jun 17, 2020, 2:40 PM Ted Ross <tr...@redhat.com> wrote:
> Proactor is a single-threaded, event-driven API for messaging. It owns the
> main execution loop and uses the pn_proactor_wait() execution to do
> background work like sending your message out the connection.
>
> I don't know what your application looks like, but I assume that you have
> your own main loop and you don't ever give proactor a chance to run. Your
> message is probably being sent when a heartbeat frame arrives from whatever
> you're connected to. This is the PN_TRANSPORT event you are seeing.
>
> -Ted
>
> On Wed, Jun 17, 2020 at 3:00 PM Adrian Florea <fl...@gmail.com>
> wrote:
>
> > Yeah... forget my last mention. Looking at what pn_proactor_done does, it
> > doesn't make sense to call it when the batch of events is null.
> >
> > On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com>
> wrote:
> >
> > > Yes.
> > > I don't call it when the pn_proactor_get() returns null.
> > >
> > > I should probably call it in this case as well..
> > >
> > >
> > > On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
> > >
> > >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <fl...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi, thanks.
> > >> > I am using the proactor.
> > >> > I need a way to clearly send a message out.
> > >> > My program has a loop and everytime it loops, I tried this:
> > >> >
> > >> > - call pn_proactor_wait --> this ends up blocking my loop, which is
> > not
> > >> > good.
> > >> >
> > >> > - call pn_proactor_get -- this does not block and returns no event
> > for a
> > >> > long while, when suddenly it gets a PN_TRANSPORT event and all my
> > >> messages
> > >> > are really sent out.
> > >> >
> > >>
> > >> Are you calling pn_proactor_done() after processing the batch of
> events
> > >> from pn_proactor_get()?
> > >>
> > >>
> > >> >
> > >> > Adrian
> > >> >
> > >> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
> > >> >
> > >> > > Hi Adrian,
> > >> > >
> > >> > > What is your program doing after it calls pn_message_send? That
> > >> function
> > >> > > queues the message for delivery but the delivery isn't actually
> > >> > transferred
> > >> > > until the application yields the control back to the Proton
> reactor
> > >> (via
> > >> > > pn_proactor_wait). If the application is doing other processing
> or
> > >> > waiting
> > >> > > on a condition or mutex, the delivery won't go out the door
> > >> immediately.
> > >> > >
> > >> > > -Ted
> > >> > >
> > >> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <
> florea.adi@gmail.com
> > >
> > >> > > wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > Any idea is welcome on this one.
> > >> > > >
> > >> > > > I am trying to send messages (via a sender link) at various
> > moments
> > >> in
> > >> > > the
> > >> > > > life of a program. I am using pn_message_send.
> > >> > > >
> > >> > > > I have set the outgoing window size to 1, on the session.
> > >> > > >
> > >> > > > The current behavior is:
> > >> > > >
> > >> > > > 1. pn_message_send completes OK
> > >> > > > 2. nothing is actually sent
> > >> > > > 3. after a while (I guess this is where I miss something) I see
> > that
> > >> > the
> > >> > > > proactor gets an event of type PN_TRANSPORT and I can see all
> > >> messages
> > >> > > > being really sent.
> > >> > > >
> > >> > > > Is there a way to achieve a "send immediate" behavior ?
> > >> > > >
> > >> > > > When a message send is invoked, I need it to really go out.
> > >> > > >
> > >> > > > many thanks for pointing me in the right direction,
> > >> > > >
> > >> > > > Adrian
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Ted Ross <tr...@redhat.com>.
Proactor is a single-threaded, event-driven API for messaging. It owns the
main execution loop and uses the pn_proactor_wait() execution to do
background work like sending your message out the connection.
I don't know what your application looks like, but I assume that you have
your own main loop and you don't ever give proactor a chance to run. Your
message is probably being sent when a heartbeat frame arrives from whatever
you're connected to. This is the PN_TRANSPORT event you are seeing.
-Ted
On Wed, Jun 17, 2020 at 3:00 PM Adrian Florea <fl...@gmail.com> wrote:
> Yeah... forget my last mention. Looking at what pn_proactor_done does, it
> doesn't make sense to call it when the batch of events is null.
>
> On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com> wrote:
>
> > Yes.
> > I don't call it when the pn_proactor_get() returns null.
> >
> > I should probably call it in this case as well..
> >
> >
> > On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
> >
> >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <fl...@gmail.com>
> >> wrote:
> >>
> >> > Hi, thanks.
> >> > I am using the proactor.
> >> > I need a way to clearly send a message out.
> >> > My program has a loop and everytime it loops, I tried this:
> >> >
> >> > - call pn_proactor_wait --> this ends up blocking my loop, which is
> not
> >> > good.
> >> >
> >> > - call pn_proactor_get -- this does not block and returns no event
> for a
> >> > long while, when suddenly it gets a PN_TRANSPORT event and all my
> >> messages
> >> > are really sent out.
> >> >
> >>
> >> Are you calling pn_proactor_done() after processing the batch of events
> >> from pn_proactor_get()?
> >>
> >>
> >> >
> >> > Adrian
> >> >
> >> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
> >> >
> >> > > Hi Adrian,
> >> > >
> >> > > What is your program doing after it calls pn_message_send? That
> >> function
> >> > > queues the message for delivery but the delivery isn't actually
> >> > transferred
> >> > > until the application yields the control back to the Proton reactor
> >> (via
> >> > > pn_proactor_wait). If the application is doing other processing or
> >> > waiting
> >> > > on a condition or mutex, the delivery won't go out the door
> >> immediately.
> >> > >
> >> > > -Ted
> >> > >
> >> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <florea.adi@gmail.com
> >
> >> > > wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > Any idea is welcome on this one.
> >> > > >
> >> > > > I am trying to send messages (via a sender link) at various
> moments
> >> in
> >> > > the
> >> > > > life of a program. I am using pn_message_send.
> >> > > >
> >> > > > I have set the outgoing window size to 1, on the session.
> >> > > >
> >> > > > The current behavior is:
> >> > > >
> >> > > > 1. pn_message_send completes OK
> >> > > > 2. nothing is actually sent
> >> > > > 3. after a while (I guess this is where I miss something) I see
> that
> >> > the
> >> > > > proactor gets an event of type PN_TRANSPORT and I can see all
> >> messages
> >> > > > being really sent.
> >> > > >
> >> > > > Is there a way to achieve a "send immediate" behavior ?
> >> > > >
> >> > > > When a message send is invoked, I need it to really go out.
> >> > > >
> >> > > > many thanks for pointing me in the right direction,
> >> > > >
> >> > > > Adrian
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
Yeah... forget my last mention. Looking at what pn_proactor_done does, it
doesn't make sense to call it when the batch of events is null.
On Wed, Jun 17, 2020, 1:50 PM Adrian Florea <fl...@gmail.com> wrote:
> Yes.
> I don't call it when the pn_proactor_get() returns null.
>
> I should probably call it in this case as well..
>
>
> On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
>
>> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <fl...@gmail.com>
>> wrote:
>>
>> > Hi, thanks.
>> > I am using the proactor.
>> > I need a way to clearly send a message out.
>> > My program has a loop and everytime it loops, I tried this:
>> >
>> > - call pn_proactor_wait --> this ends up blocking my loop, which is not
>> > good.
>> >
>> > - call pn_proactor_get -- this does not block and returns no event for a
>> > long while, when suddenly it gets a PN_TRANSPORT event and all my
>> messages
>> > are really sent out.
>> >
>>
>> Are you calling pn_proactor_done() after processing the batch of events
>> from pn_proactor_get()?
>>
>>
>> >
>> > Adrian
>> >
>> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
>> >
>> > > Hi Adrian,
>> > >
>> > > What is your program doing after it calls pn_message_send? That
>> function
>> > > queues the message for delivery but the delivery isn't actually
>> > transferred
>> > > until the application yields the control back to the Proton reactor
>> (via
>> > > pn_proactor_wait). If the application is doing other processing or
>> > waiting
>> > > on a condition or mutex, the delivery won't go out the door
>> immediately.
>> > >
>> > > -Ted
>> > >
>> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <fl...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > Any idea is welcome on this one.
>> > > >
>> > > > I am trying to send messages (via a sender link) at various moments
>> in
>> > > the
>> > > > life of a program. I am using pn_message_send.
>> > > >
>> > > > I have set the outgoing window size to 1, on the session.
>> > > >
>> > > > The current behavior is:
>> > > >
>> > > > 1. pn_message_send completes OK
>> > > > 2. nothing is actually sent
>> > > > 3. after a while (I guess this is where I miss something) I see that
>> > the
>> > > > proactor gets an event of type PN_TRANSPORT and I can see all
>> messages
>> > > > being really sent.
>> > > >
>> > > > Is there a way to achieve a "send immediate" behavior ?
>> > > >
>> > > > When a message send is invoked, I need it to really go out.
>> > > >
>> > > > many thanks for pointing me in the right direction,
>> > > >
>> > > > Adrian
>> > > >
>> > >
>> >
>>
>
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
Yes.
I don't call it when the pn_proactor_get() returns null.
I should probably call it in this case as well..
On Wed, Jun 17, 2020, 1:30 PM Ted Ross <tr...@redhat.com> wrote:
> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <fl...@gmail.com>
> wrote:
>
> > Hi, thanks.
> > I am using the proactor.
> > I need a way to clearly send a message out.
> > My program has a loop and everytime it loops, I tried this:
> >
> > - call pn_proactor_wait --> this ends up blocking my loop, which is not
> > good.
> >
> > - call pn_proactor_get -- this does not block and returns no event for a
> > long while, when suddenly it gets a PN_TRANSPORT event and all my
> messages
> > are really sent out.
> >
>
> Are you calling pn_proactor_done() after processing the batch of events
> from pn_proactor_get()?
>
>
> >
> > Adrian
> >
> > On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
> >
> > > Hi Adrian,
> > >
> > > What is your program doing after it calls pn_message_send? That
> function
> > > queues the message for delivery but the delivery isn't actually
> > transferred
> > > until the application yields the control back to the Proton reactor
> (via
> > > pn_proactor_wait). If the application is doing other processing or
> > waiting
> > > on a condition or mutex, the delivery won't go out the door
> immediately.
> > >
> > > -Ted
> > >
> > > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <fl...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Any idea is welcome on this one.
> > > >
> > > > I am trying to send messages (via a sender link) at various moments
> in
> > > the
> > > > life of a program. I am using pn_message_send.
> > > >
> > > > I have set the outgoing window size to 1, on the session.
> > > >
> > > > The current behavior is:
> > > >
> > > > 1. pn_message_send completes OK
> > > > 2. nothing is actually sent
> > > > 3. after a while (I guess this is where I miss something) I see that
> > the
> > > > proactor gets an event of type PN_TRANSPORT and I can see all
> messages
> > > > being really sent.
> > > >
> > > > Is there a way to achieve a "send immediate" behavior ?
> > > >
> > > > When a message send is invoked, I need it to really go out.
> > > >
> > > > many thanks for pointing me in the right direction,
> > > >
> > > > Adrian
> > > >
> > >
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Ted Ross <tr...@redhat.com>.
On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea <fl...@gmail.com> wrote:
> Hi, thanks.
> I am using the proactor.
> I need a way to clearly send a message out.
> My program has a loop and everytime it loops, I tried this:
>
> - call pn_proactor_wait --> this ends up blocking my loop, which is not
> good.
>
> - call pn_proactor_get -- this does not block and returns no event for a
> long while, when suddenly it gets a PN_TRANSPORT event and all my messages
> are really sent out.
>
Are you calling pn_proactor_done() after processing the batch of events
from pn_proactor_get()?
>
> Adrian
>
> On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
>
> > Hi Adrian,
> >
> > What is your program doing after it calls pn_message_send? That function
> > queues the message for delivery but the delivery isn't actually
> transferred
> > until the application yields the control back to the Proton reactor (via
> > pn_proactor_wait). If the application is doing other processing or
> waiting
> > on a condition or mutex, the delivery won't go out the door immediately.
> >
> > -Ted
> >
> > On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <fl...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Any idea is welcome on this one.
> > >
> > > I am trying to send messages (via a sender link) at various moments in
> > the
> > > life of a program. I am using pn_message_send.
> > >
> > > I have set the outgoing window size to 1, on the session.
> > >
> > > The current behavior is:
> > >
> > > 1. pn_message_send completes OK
> > > 2. nothing is actually sent
> > > 3. after a while (I guess this is where I miss something) I see that
> the
> > > proactor gets an event of type PN_TRANSPORT and I can see all messages
> > > being really sent.
> > >
> > > Is there a way to achieve a "send immediate" behavior ?
> > >
> > > When a message send is invoked, I need it to really go out.
> > >
> > > many thanks for pointing me in the right direction,
> > >
> > > Adrian
> > >
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Adrian Florea <fl...@gmail.com>.
Hi, thanks.
I am using the proactor.
I need a way to clearly send a message out.
My program has a loop and everytime it loops, I tried this:
- call pn_proactor_wait --> this ends up blocking my loop, which is not
good.
- call pn_proactor_get -- this does not block and returns no event for a
long while, when suddenly it gets a PN_TRANSPORT event and all my messages
are really sent out.
Adrian
On Wed, Jun 17, 2020, 12:36 PM Ted Ross <tr...@redhat.com> wrote:
> Hi Adrian,
>
> What is your program doing after it calls pn_message_send? That function
> queues the message for delivery but the delivery isn't actually transferred
> until the application yields the control back to the Proton reactor (via
> pn_proactor_wait). If the application is doing other processing or waiting
> on a condition or mutex, the delivery won't go out the door immediately.
>
> -Ted
>
> On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <fl...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Any idea is welcome on this one.
> >
> > I am trying to send messages (via a sender link) at various moments in
> the
> > life of a program. I am using pn_message_send.
> >
> > I have set the outgoing window size to 1, on the session.
> >
> > The current behavior is:
> >
> > 1. pn_message_send completes OK
> > 2. nothing is actually sent
> > 3. after a while (I guess this is where I miss something) I see that the
> > proactor gets an event of type PN_TRANSPORT and I can see all messages
> > being really sent.
> >
> > Is there a way to achieve a "send immediate" behavior ?
> >
> > When a message send is invoked, I need it to really go out.
> >
> > many thanks for pointing me in the right direction,
> >
> > Adrian
> >
>
Re: Qpid proton c -- pn_message_send
Posted by Ted Ross <tr...@redhat.com>.
Hi Adrian,
What is your program doing after it calls pn_message_send? That function
queues the message for delivery but the delivery isn't actually transferred
until the application yields the control back to the Proton reactor (via
pn_proactor_wait). If the application is doing other processing or waiting
on a condition or mutex, the delivery won't go out the door immediately.
-Ted
On Wed, Jun 17, 2020 at 1:11 PM Adrian Florea <fl...@gmail.com> wrote:
> Hi,
>
> Any idea is welcome on this one.
>
> I am trying to send messages (via a sender link) at various moments in the
> life of a program. I am using pn_message_send.
>
> I have set the outgoing window size to 1, on the session.
>
> The current behavior is:
>
> 1. pn_message_send completes OK
> 2. nothing is actually sent
> 3. after a while (I guess this is where I miss something) I see that the
> proactor gets an event of type PN_TRANSPORT and I can see all messages
> being really sent.
>
> Is there a way to achieve a "send immediate" behavior ?
>
> When a message send is invoked, I need it to really go out.
>
> many thanks for pointing me in the right direction,
>
> Adrian
>