# Rivers and Executors **URL:** \ **Category:** Elasticsearch\ **Created:** [May 28, 2013, 7:32pm UTC](https://discuss.elastic.co/t/rivers-and-executors/12158 "2013-05-28T19:32:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Sylvain\_Wallez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_wallez/32/2319_2.png) [@Sylvain\_Wallez](https://discuss.elastic.co/u/Sylvain_Wallez)\ **Post date:** [May 28, 2013, 7:32pm UTC](https://discuss.elastic.co/t/rivers-and-executors/12158/1 "2013-05-28T19:32:18Z")
Hi all, I'm writing my first river that pulls data from several relational databases, and I'm wondering how to best schedule periodic indexing tasks. There is this nice ThreadPool class in ES that already has everything: schedulers, executors of various kinds, etc. Yet it seems that most rivers create their own threads or executors. So is ThreadPool considered an internal API, or is it safe to use it to schedule tasks in a river? Thanks, Sylvain -- Sylvain Wallez - [http://bluxte.net](http://bluxte.net) -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [May 28, 2013, 9:03pm UTC](https://discuss.elastic.co/t/rivers-and-executors/12158/2 "2013-05-28T21:03:01Z")
What is an internal API? What is safe use? It depends. ES thread pools are working but are always subject of change for improvement. In case ES may change thread pool code and you can not migrate your API usage, you can always copy old working thread pool code into your plugin. I also see a challenge since there is no "stability policy for API change" yet, but I hope in the future (after 1.00) methods will be marked "deprecated" and not removed or changed that fast from one version to the other. Jörg On Tuesday, May 28, 2013 9:32:18 PM UTC+2, Sylvain Wallez wrote: > So is ThreadPool considered an internal API, or is it safe to use it to > schedule tasks in a river? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Sylvain\_Wallez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_wallez/32/2319_2.png) [@Sylvain\_Wallez](https://discuss.elastic.co/u/Sylvain_Wallez)\ **Post date:** [May 28, 2013, 10:07pm UTC](https://discuss.elastic.co/t/rivers-and-executors/12158/3 "2013-05-28T22:07:29Z")
Sorry, by "safe" I was actually wondering if there are some risks of breaking the normal function of ES by using threads that are dedicated to internal tasks and sepecifically tuned for this, e.g. for small duration tasks, compared to the time spent waiting for a database to execute a complex query. Sylvain On Tuesday, May 28, 2013 11:03:01 PM UTC+2, Jörg Prante wrote: > What is an internal API? What is safe use? It depends. ES thread pools are > working but are always subject of change for improvement. In case ES may > change thread pool code and you can not migrate your API usage, you can > always copy old working thread pool code into your plugin. I also see a > challenge since there is no "stability policy for API change" yet, but I > hope in the future (after 1.00) methods will be marked "deprecated" and not > removed or changed that fast from one version to the other. > > Jörg > > On Tuesday, May 28, 2013 9:32:18 PM UTC+2, Sylvain Wallez wrote: > > > So is ThreadPool considered an internal API, or is it safe to use it to > > schedule tasks in a river? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [May 28, 2013, 10:14pm UTC](https://discuss.elastic.co/t/rivers-and-executors/12158/4 "2013-05-28T22:14:59Z")
I don't know what you are really after, but by using your own service/thread pool via the methods in org.elasticsearch.common.util.concurrent.EsExecutors you can't hardly interfere with anything (unless you want to drown the VM with unbounded thread pools but you don't, I'm sure). Jörg Am 29.05.13 00:07, schrieb Sylvain Wallez: > Sorry, by "safe" I was actually wondering if there are some risks of > breaking the normal function of ES by using threads that are dedicated > to internal tasks and sepecifically tuned for this, e.g. for small > duration tasks, compared to the time spent waiting for a database to > execute a complex query. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Sylvain\_Wallez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_wallez/32/2319_2.png) [@Sylvain\_Wallez](https://discuss.elastic.co/u/Sylvain_Wallez)\ **Post date:** [May 29, 2013, 2:29pm UTC](https://discuss.elastic.co/t/rivers-and-executors/12158/5 "2013-05-29T14:29:48Z")
I was only trying to limit the number of thread collections living independently in the system, and looking for advices on best practices. But you're right. Since I'll only need a couple of additional threads, EsExecutors sounds good. Thanks! Sylvain On Wednesday, May 29, 2013 12:14:59 AM UTC+2, Jörg Prante wrote: > I don't know what you are really after, but by using your own > service/thread pool via the methods in > org.elasticsearch.common.util.concurrent.EsExecutors you can't hardly > interfere with anything (unless you want to drown the VM with unbounded > thread pools but you don't, I'm sure). > > Jörg > > Am 29.05.13 00:07, schrieb Sylvain Wallez: > > > Sorry, by "safe" I was actually wondering if there are some risks of > > breaking the normal function of ES by using threads that are dedicated > > to internal tasks and sepecifically tuned for this, e.g. for small > > duration tasks, compared to the time spent waiting for a database to > > execute a complex query. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:34am UTC](https://discuss.elastic.co/t/rivers-and-executors/12158/6 "2017-07-06T02:34:04Z")