Re: Proton-J Reactor sending delay

[Bozo Dragojevic]

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
s/quark/proton/

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
>>>
>>>

Re: Proton-J Reactor sending delay

[Bozo Dragojevic]

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
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
>>
>>

Re: Proton-J Reactor sending delay

[Robbie Gemmell]

It looks to already be configurable, e.g. you could call the same
method to update the value from the thread running the reactor,
perhaps in the onReactorInit() handler. That said, I'm not sure youd
would normally want to, except maybe to increase it, which is
presumably not what you were thinking here when asking.

My limited understanding of it is that the timeout should only really
have an effect when the reactor thinks it has nothing else to do, with
the value dictating how long the reactor awaits something new to do,
e.g new data arriving to give it work, before it fires off another
quiesced event. As such I would guess that in this case the reactor is
either incorrect in thinking that it has nothing to do, or perhaps
isn't being used in the intended/required fashion (see sub-thread from
Ken's mail).

Robbie

On 25 February 2016 at 17:45, Andrew Buckley <and...@microsoft.com> wrote:
> 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
>

Re: Proton-J Reactor sending delay

[Robbie Gemmell]

Yes, where/when/how send is being called might be important, thats one
reason why I asked for an example showing the behaviour.

The java reactor does also has a wakeup method to prod the thread
blocked in process() to life, which notes itself to be the only method
you can call at the same time another thread is using the reactor.

Robbie

On 25 February 2016 at 19:03, Ken Giusti <kgiu...@redhat.com> 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
>>
>>
>
> --
> -K
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

Re: Proton-J Reactor sending delay

[Ken Giusti]

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
> 
> 

-- 
-K

RE: Proton-J Reactor sending delay

[Andrew Buckley]

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

Re: Proton-J Reactor sending delay

[Robbie Gemmell]

On 13 February 2016 at 00:28, Andrew Buckley  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)