Hi Akila,
On Wed, Jul 22, 2015 at 12:32 AM, Akila Ravihansa Perera wrote:
> Hi,
>
> While going through the changes that were made to event listeners, I
> noticed that InstanceNotifierEventReceiver [1] does not have an executor
> service while other event listeners do. Was this done on purpose?
>
Hi,
While going through the changes that were made to event listeners, I
noticed that InstanceNotifierEventReceiver [1] does not have an executor
service while other event listeners do. Was this done on purpose?
[1]
https://github.com/apache/stratos/blob/master/components/org.apache.stratos.messa
+1 for the improvement Isuru. Probably we should do a hangout on these
implementation.
On Sun, Nov 16, 2014 at 8:06 PM, Isuru Haththotuwa
wrote:
> Thanks all. Furthermore, I plan to do the following refactoring:
>
>
>- An abstraction and MQTT based implementation of a message receiver
>w
Thanks all. Furthermore, I plan to do the following refactoring:
- An abstraction and MQTT based implementation of a message receiver
which can handle the re-connection logic that we are currently missing.
- Abstraction for MessageDelegators
- Abstraction for local event receiver
O
Hi,
While going through the code I tried to understand what the threads are
doing,
StratosManagerTopologyEventReceiver
creates TopologyEventReceiver and add event listerns - Not an iterative
process. See the run method just keep on sleeping while terminates become
true
TopologyEventReceiver
cre
Yes, better to do this improvement in all the message broker topic
listeners.
On Fri, Nov 14, 2014 at 1:36 PM, Chamila De Alwis wrote:
> Hi,
>
> Furthermore, it seems this is a pattern followed all over Stratos, where
> each component has a {component}{topic}EventReceiver runnable. Shouldn't we
Hi,
Furthermore, it seems this is a pattern followed all over Stratos, where
each component has a {component}{topic}EventReceiver runnable. Shouldn't we
consider them too? If we do, then this will be a major test task.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.
Hi,
It seems the purpose of the StratosManagerTopologyEventReceiver is to
provide methods to add event listeners. We can have this functionality in a
non-runnable class too. However from the TopologyEventReceiver onwards I
think it's essential to keep the threading model because of the nature of
p
Yes better to do this improvement Isuru.
On Fri, Nov 14, 2014 at 12:20 PM, Udara Liyanage wrote:
> Hi Isuru,
>
> +1 pooling for threads is an unnecessary overhead.
>
> On Fri, Nov 14, 2014 at 12:03 PM, Isuru Haththotuwa
> wrote:
>
>> Hi Devs,
>>
>> This thread is to discuss $subject.
>>
>> Let
Hi Isuru,
+1 pooling for threads is an unnecessary overhead.
On Fri, Nov 14, 2014 at 12:03 PM, Isuru Haththotuwa
wrote:
> Hi Devs,
>
> This thread is to discuss $subject.
>
> Let me explain the current flow, taking Topology event listener in Stratos
> Manager as an example.
>
>1. SM Topolog
Hi Devs,
This thread is to discuss $subject.
Let me explain the current flow, taking Topology event listener in Stratos
Manager as an example.
1. SM Topology event receiver is started in a separate thread
2. In the SM Topology event receiver thread, we start another thread
with an insta
11 matches
Mail list logo
