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.chamiladealwis.com
On Fri, Nov 14, 2014 at 1:17 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Yes better to do this improvement Isuru.
>
> On Fri, Nov 14, 2014 at 12:20 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
>> Hi Isuru,
>>
>> +1 pooling for threads is an unnecessary overhead.
>>
>> On Fri, Nov 14, 2014 at 12:03 PM, Isuru Haththotuwa <isu...@apache.org>
>> 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 Topology event receiver is started in a separate thread
>>> 2. In the SM Topology event receiver thread, we start another thread
>>> with an instance of messaging's TopologyEventReceiver class.
>>> 3. Again in the TopologyEventReceiver thread, we create couple of
>>> more threads for the Topology event message delegator and topic
>>> subscriber.
>>>
>>> IMHO there is no need to create all these threads. AFAIU, what we need
>>> are three threads which will:
>>>
>>> 1. Listen to the events
>>> 2. Handles delegation
>>> 3. Updates the local topology models
>>>
>>> Also, we can use java ExecutorServices handle graceful
>>> starting/termination of threads. Currently, we are doing sleeping/looping
>>> mechanism to keep the threads alive, which can be replaced with
>>> ExecutorService.
>>>
>>> WDYT?
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> +94 716 358 048* <http://wso2.com/>*
>>>
>>>
>>>
>>
>>
>> --
>>
>> Udara Liyanage
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> lean. enterprise. middleware
>>
>> web: http://udaraliyanage.wordpress.com
>> phone: +94 71 443 6897
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
