IMO it is ok to have separate thread pools for each monitors.With the separate thread pool for each monitor makes sure that those tasks get run regardless of how busy the rest of the monitors are.I don't think we can get any advantage by having common thread pool for this.
But we need to introduce the thread pool size is in configuration level. Also we need to give the thread pool identifier in align with the related task that thread pool assign to.That provide an option to user to control thread pool size as accordingly. Also I am not quite sure why we need to such a big number of threads(1500 when deploying 2 or 3 apps). May be we can recheck the thread creation logic and fine tune that. Thanks, Gayan On Sat, Nov 21, 2015 at 8:08 PM, Reka Thirunavukkarasu <r...@wso2.com> wrote: > Hi Akila, > > Yah..I think that we can share a common thread pool per monitor. AFAIK, > there was no specific reason to maintain thread pool per monitor object. > > @Gayan, Do you aware of any particular reason why we did like that? > > All the monitors need one thread allocated for periodic execution. Other > than that, based on child events, the particular processing will be > executed as thread. So i believe that we can share the thread pool and make > it to 100 by default. May be we can increase the thread pool size > proportional to the number of nodes in the application. We can come up with > that value for the thread pool size. > > Thanks, > Reka > > On Sat, Nov 21, 2015 at 1:20 PM, Akila Ravihansa Perera < > raviha...@wso2.com> wrote: > >> Hi, >> >> I noticed that ExecutorService objects are created in the constructors of >> ClusterMonitor, ApplicationMonitor, GroupMonitor, ParentComponentMonitor >> classes. These thread pools' size is 100 [1, 2, 3, 4]. >> >> Any idea why thread pools are created per monitor object? Is it not >> possible to share a common thread pool as per the current design? >> >> Stratos server thread count goes beyond 1500 when deploying 2 or 3 apps. >> And it keeps growing proportional to the deployed app count. This is a very >> high resource usage. >> >> [1] >> https://github.com/apache/stratos/blob/stratos-4.1.x/components/org.apache.stratos.autoscaler/src/main/java/org/apache/stratos/autoscaler/monitor/cluster/ClusterMonitor.java#L108 >> >> [2] >> https://github.com/apache/stratos/blob/stratos-4.1.x/components/org.apache.stratos.autoscaler/src/main/java/org/apache/stratos/autoscaler/monitor/component/ApplicationMonitor.java#L82 >> >> [3] >> https://github.com/apache/stratos/blob/stratos-4.1.x/components/org.apache.stratos.autoscaler/src/main/java/org/apache/stratos/autoscaler/monitor/component/GroupMonitor.java#L88 >> >> [4] >> https://github.com/apache/stratos/blob/stratos-4.1.x/components/org.apache.stratos.autoscaler/src/main/java/org/apache/stratos/autoscaler/monitor/component/ParentComponentMonitor.java#L112 >> >> Thanks. >> >> -- >> Akila Ravihansa Perera >> WSO2 Inc.; http://wso2.com/ >> >> Blog: http://ravihansa3000.blogspot.com >> > > > > -- > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > Mobile: +94776442007 > > > -- Gayan Gunarathne Technical Lead, WSO2 Inc. (http://wso2.com) Committer & PMC Member, Apache Stratos email : gay...@wso2.com | mobile : +94 775030545 <%2B94%20766819985>
