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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> > >> 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 <[email protected]> wrote: > >> > > > >> > >> On Wed, Jun 17, 2020 at 2:19 PM Adrian Florea < > [email protected]> > >> > >> 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 <[email protected]> > 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 < > >> [email protected] > >> > > > >> > >> > > 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 > >> > >> > > > > >> > >> > > > >> > >> > > >> > >> > >> > > > >> > > >> > > >
