Iiuc, calling anything except wakeup from outside the reactor thread is

Reactor (whole proton-c and proton-j) has no locks to protect against
such use.

The general pattern is to trigger your application from a handler for
'on reactor init' and
add that handler to the reactor before starting it.

To send messages from another thread, one needs to build that
functionality around proton. -- maybe it would make sense to add one
lock to quark to allow reactor.schedule() to be called from another
thread, that would simplify things a lot.

Right now, I /think/ you cannot do it without a threadsafe queue,
producer needs to call reactor.wakeup() and consumer of the queue can be
a handler on the quiesced event and polls the queue (must not block).


On 25. 02. 16 20.03, Ken Giusti wrote:
> Andrew - are you calling send() from within a reactor callback?  Or from 
> another thread?
> I'm not very familiar with the Java reactor, but the C reactor has a method 
> called pn_reactor_wakeup() which causes it to immediately return from the 
> blocking select() call.
> -K
> ----- Original Message -----
>> From: "Andrew Buckley" <and...@microsoft.com>
>> To: d...@qpid.apache.org, proton@qpid.apache.org
>> Sent: Thursday, February 25, 2016 12:45:04 PM
>> Subject: RE: Proton-J Reactor sending delay
>> Ah, thanks Robbie. Yes I do now notice the 3141ms timeout inside run(). Are
>> there plans to make that timeout configurable? At least from my point of
>> view, 3 seconds is quite a long time to wait between calling send and the
>> action actually being performed, and applications using the Reactor do
>> suffer a bit of a blow in performance because of this.
>> Thanks,
>> -Andrew
>> -----Original Message-----
>> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
>> Sent: Monday, February 15, 2016 3:47 AM
>> To: d...@qpid.apache.org; proton@qpid.apache.org
>> Subject: Re: Proton-J Reactor sending delay
>> On 13 February 2016 at 00:28, Andrew Buckley <and...@microsoft.com> wrote:
>>> I'm using the reactor with Proton-J and have noticed that there is a 2-4
>>> second delay between when I call send() on a particular link and when that
>>> transfer frame actually goes out. Is this expected behavior? If so, are
>>> there plans to improve on this? And if not, have you seen this in any
>>> other scenario and might you have any ideas what could be causing it?
>>> Thanks,
>>> -Andrew Buckley
>> Hi Andrew,
>> While im no expert on the reactor, I'd be surprised if that was expected, and
>> I can't say I'm aware of it being mentioned before.
>> One thing that springs to mind from previous discussion [about proton-c
>> reactor] is that when the reactor has a particular thread dedicated to
>> running it, it sets a 3141ms timeout on its selector meaning it wakes up at
>> that period when it is 'quiesced' (has nothing to do). Seems like perhaps
>> that could be related given your note of 2-4sec.
>> Do you have an example showing the behaviour?
>> Robbie
>> (added proton@ as well, in case anyone only paying attention there has
>> thoughts)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional
>> commands, e-mail: dev-h...@qpid.apache.org

Reply via email to