On 02/09/16 13:41, "Stefan Egli" wrote:
>On 02/09/16 13:26, "Chetan Mehrotra" wrote:
>
>>Listener for local Change
>>--
>>
>>Such a listener is more particular about type of change and is doing
>>some persisted state change i.e. like registering a job, invoking so
Hi Chetan,
(see below)
On 02/09/16 13:26, "Chetan Mehrotra" wrote:
>On Fri, Sep 2, 2016 at 4:00 PM, Stefan Egli wrote:
>> If we
>> separate listeners into purely internal vs external, then a queue as a
>>whole
>> is either purely internal or external and we no longer have this issue.
>
>Not su
That's an interesting approach. I kind of like it, especially as it
provides a path to get rid of external listeners one day completely.
Carsten
> Hi,
>
> As you're probably aware there are currently several different issues being
> worked upon related to the observation queue limit problem ([0]
On Fri, Sep 2, 2016 at 4:00 PM, Stefan Egli wrote:
> If we
> separate listeners into purely internal vs external, then a queue as a whole
> is either purely internal or external and we no longer have this issue.
Not sure here on how this would work. The observation queue is made up
of ContentChan
Perhaps for backwards compatibility we could auto-create 2 listeners for
the case where a listener is registered without ExcludeInternal or
ExcludeExternal - and issue a corresponding, loud, WARN.
On 02/09/16 12:30, "Stefan Egli" wrote:
>Hi,
>
>As you're probably aware there are currently severa
Hi,
As you're probably aware there are currently several different issues being
worked upon related to the observation queue limit problem ([0], epic [1]).
I wanted to discuss yet another improvement and first ask what the list
thinks.
What about requiring observation listeners to either consume
