On 26. 02. 16 15.36, Bozo Dragojevic wrote:
> Iiuc, calling anything except wakeup from outside the reactor thread is
> forbidden.
> 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

Context switch error :)
> 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).
> Bozzo
> 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