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 <florea....@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 <florea....@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 <florea....@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 <florea....@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....@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....@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 > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > > > > >> > > > >> > > > > > >
