Java ThreadPoolExecutor - достучаться до working threads

[Palych]

Good luck!

[Picasso]

Это не подойдет?
http://code.google.com/p/guava-librarie ... eExplained

[Интеррапт]

Это не подойдет?
http://code.google.com/p/guava-librarie ... eExplained

Так топикстартер категорически отказывается хранить ссылки на Runnable в коллекции
При этом хочет иметь доступ к списку runnable.

[Интеррапт]

Опять возникла необходимость добраться до threads, скормленных в ThreadPoolExecutor для исполнения. Единственная известная мне возможность это держать на стороне collection ссылок на эти threads. Но это означает, что надо как-то чистить эту collection, чтобы избавлятья от ссылок на terminated threads, что довольно геморройно. Может кто знает, как получить доступ к working threads в самом Executore?

А почему геморройно чистить коллекцию ссылок? Наследовали класс ThreadPoolExecutor, там же можете добавить коллекцию ссылок на Runnable. Овверайднули там afterExecute метод и удалили из коллекции переданную вам ссылку на Runnable. Аналогично в beforeExecute можете добавлять Runnable в эту коллекцию. Или я не совсем понял вашу проблему?

Да все правильно, можно конечно и эхтендить ThreadPoolExecutor или научить воркера удалять самого себя из списка. Но ведь блин ThreadPoolExecutor уже хранит этих воркеров в внутренней collection. Вот мне гондурас и не дает покоя по этому поводу. В смысле как до этой collection добраться.

Никак, кроме как через reflections. И не надо добираться - потому что сегодня это коллекция, завтра они в следующей версии Java решат сделать это массивом, а потом, на какой-то хитрой OS, вообще не будут хранить коллекцию, например, потому что у этой OS уже есть родной API для thread pool.

Без разницы как это сделано внутри executora. Мне бы доступ к active worker threadам получить. Reflection не подходит.

Ну вы же небось сами документацию посмотрели и увидели, что этот класс не экспозает никакие методы для получения списка потоков. О каком хотении тогда может идти речь? Если вам лень написать 20 строчек когда, чтобы самому это имплементировать через коллекцию, ну ищите тогда в интернете, может кто-то это уже сделал за вас.

[Montchik]

Это не подойдет?
http://code.google.com/p/guava-librarie ... eExplained

Ага, в смысле нет, не подходит. См выше.

[Montchik]

А почему геморройно чистить коллекцию ссылок? Наследовали класс ThreadPoolExecutor, там же можете добавить коллекцию ссылок на Runnable. Овверайднули там afterExecute метод и удалили из коллекции переданную вам ссылку на Runnable. Аналогично в beforeExecute можете добавлять Runnable в эту коллекцию. Или я не совсем понял вашу проблему?

Да все правильно, можно конечно и эхтендить ThreadPoolExecutor или научить воркера удалять самого себя из списка. Но ведь блин ThreadPoolExecutor уже хранит этих воркеров в внутренней collection. Вот мне гондурас и не дает покоя по этому поводу. В смысле как до этой collection добраться.

Никак, кроме как через reflections. И не надо добираться - потому что сегодня это коллекция, завтра они в следующей версии Java решат сделать это массивом, а потом, на какой-то хитрой OS, вообще не будут хранить коллекцию, например, потому что у этой OS уже есть родной API для thread pool.

Без разницы как это сделано внутри executora. Мне бы доступ к active worker threadам получить. Reflection не подходит.

Ну вы же небось сами документацию посмотрели и увидели, что этот класс не экспозает никакие методы для получения списка потоков. О каком хотении тогда может идти речь? Если вам лень написать 20 строчек когда, чтобы самому это имплементировать через коллекцию, ну ищите тогда в интернете, может кто-то это уже сделал за вас.

Я конечно же читал доку, но думал, может упустил чего. Поэтому здесь и спросил.

[Picasso]

Это не подойдет?
http://code.google.com/p/guava-librarie ... eExplained

Ага, в смысле нет, не подходит. См выше.

Ну как запасной вариант. Коли за внутреннюю коллекцию лупят инкапсуляцией по пальцам, так завести внешнюю. А ListenableFuture поручить чтоб оно назад коллбеками сообщало - "командир, меня тут убили - обновите список части".

[Montchik]

Хех, дык я где-то так и делаю. Только ручками, без пользования всякого там гуана. Интересная идея была заекстендить ThreadPoolExecutor и перекрыть executeBefore and executeAfter методы. Наверное так и попробую в следующий раз.

[Picasso]

Я блин забыл что ты ж фреймворки не любишь. А за гуано - ответишь. =) Перед котом в наушниках какминимум.

[Интеррапт]

Я конечно же читал доку, но думал, может упустил чего. Поэтому здесь и спросил.

Еще как вариант, это создавать ThreadPoolExecutor напрямую через конструктор. Тогда там в конструктор можно указать BlockingQueue<Runnable> как параметр. И собственно в этот BlockingQueue будут автоматически добавляться и удаляться Runnable обьекты.

[crypto5]

Я конечно же читал доку, но думал, может упустил чего. Поэтому здесь и спросил.

Еще как вариант, это создавать ThreadPoolExecutor напрямую через конструктор. Тогда там в конструктор можно указать BlockingQueue<Runnable> как параметр. И собственно в этот BlockingQueue будут автоматически добавляться и удаляться Runnable обьекты.

Не факт что в этой queue будут активные таски. В доке так и написано, что юзать только длйха дебага и мониторинга, никаких гарантий нету.

[Montchik]

Пробовал уже. Этo waiting queue - для objects waiting for threads to become available, а не тех, что уже ранятся.

[Montchik]

Я блин забыл что ты ж фреймворки не любишь. А за гуано - ответишь. =) Перед котом в наушниках какминимум.

Как вы лодку назовете...

[Komissar]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

[crypto5]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Им наверное не нужно запускать в бекграунде и стопать запросы выполняющиея часами.

[Zorkus]

Опять возникла необходимость добраться до threads, скормленных в ThreadPoolExecutor для исполнения. Единственная известная мне возможность это держать на стороне collection ссылок на эти threads. Но это означает, что надо как-то чистить эту collection, чтобы избавлятья от ссылок на terminated threads, что довольно геморройно. Может кто знает, как получить доступ к working threads в самом Executore?

А почему геморройно чистить коллекцию ссылок? Наследовали класс ThreadPoolExecutor, там же можете добавить коллекцию ссылок на Runnable. Овверайднули там afterExecute метод и удалили из коллекции переданную вам ссылку на Runnable. Аналогично в beforeExecute можете добавлять Runnable в эту коллекцию. Или я не совсем понял вашу проблему?

Да все правильно, можно конечно и эхтендить ThreadPoolExecutor или научить воркера удалять самого себя из списка. Но ведь блин ThreadPoolExecutor уже хранит этих воркеров в внутренней collection. Вот мне гондурас и не дает покоя по этому поводу. В смысле как до этой collection добраться.

Никак, кроме как через reflections. И не надо добираться - потому что сегодня это коллекция, завтра они в следующей версии Java решат сделать это массивом, а потом, на какой-то хитрой OS, вообще не будут хранить коллекцию, например, потому что у этой OS уже есть родной API для thread pool.

Если единственная проблема автора в том, что нужен доступ к этой коллекции, а злые дизайнеры j.u.c. не открыли ее в паблик, то в чем проблема, через reflection, setAccessible(true) и вперед. Будет работать всегда и без всякого геморроя и оверхеда за исключением двух случаев:

1) прога работает в jvm с суперстрогим security manager, которые не дает дергать через reflection поля. Я в реальности такого не встречал ни разу.
2) в следующем JDK структура этого пуля изменится. Ну и черт с ним, во время апгрейда переписать за 5 минут на массив или чего там. Я считаю, юзать приватные апи такие вещей как j.u.c. вполне нормально и цивильно.

[Zorkus]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Ну слабать-то конечно слабали, быстро, ниши захватили, (за что им респект! писали бы сразу на яве или С++, до сих пор бы сидели на форумах, и обсуждали как настроить тред пулы, вместо того чтобы IPO уже отмечать), но потом все равно уперлись в проблемы производительности. И начали кто создавать хипхоп c кассандрой, кто переписывать куски сайта с руби на скалу, кто еще чего

[Zorkus]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Им наверное не нужно запускать в бекграунде и стопать запросы выполняющиея часами.

Есть прикольная книжка от инженегров твиттера (meap so far), Big Data называется. Если не читали, советую. Там любопытные вещи пишут об этом в том числе.

[crypto5]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Им наверное не нужно запускать в бекграунде и стопать запросы выполняющиея часами.

Есть прикольная книжка от инженегров твиттера (meap so far), Big Data называется. Если не читали, советую. Там любопытные вещи пишут об этом в том числе.

Я книжек про бигдата прочитал уже достаточно, это как то относится к топику?

[Интеррапт]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Им наверное не нужно запускать в бекграунде и стопать запросы выполняющиея часами.

Есть прикольная книжка от инженегров твиттера (meap so far), Big Data называется. Если не читали, советую. Там любопытные вещи пишут об этом в том числе.

А что именно? Описание какого-нибудь асинхронного map/reduce ?

[crypto5]

Опять возникла необходимость добраться до threads, скормленных в ThreadPoolExecutor для исполнения. Единственная известная мне возможность это держать на стороне collection ссылок на эти threads. Но это означает, что надо как-то чистить эту collection, чтобы избавлятья от ссылок на terminated threads, что довольно геморройно. Может кто знает, как получить доступ к working threads в самом Executore?

А почему геморройно чистить коллекцию ссылок? Наследовали класс ThreadPoolExecutor, там же можете добавить коллекцию ссылок на Runnable. Овверайднули там afterExecute метод и удалили из коллекции переданную вам ссылку на Runnable. Аналогично в beforeExecute можете добавлять Runnable в эту коллекцию. Или я не совсем понял вашу проблему?

Да все правильно, можно конечно и эхтендить ThreadPoolExecutor или научить воркера удалять самого себя из списка. Но ведь блин ThreadPoolExecutor уже хранит этих воркеров в внутренней collection. Вот мне гондурас и не дает покоя по этому поводу. В смысле как до этой collection добраться.

Никак, кроме как через reflections. И не надо добираться - потому что сегодня это коллекция, завтра они в следующей версии Java решат сделать это массивом, а потом, на какой-то хитрой OS, вообще не будут хранить коллекцию, например, потому что у этой OS уже есть родной API для thread pool.

Если единственная проблема автора в том, что нужен доступ к этой коллекции, а злые дизайнеры j.u.c. не открыли ее в паблик, то в чем проблема, через reflection, setAccessible(true) и вперед. Будет работать всегда и без всякого геморроя и оверхеда за исключением двух случаев:

1) прога работает в jvm с суперстрогим security manager, которые не дает дергать через reflection поля. Я в реальности такого не встречал ни разу.
2) в следующем JDK структура этого пуля изменится. Ну и черт с ним, во время апгрейда переписать за 5 минут на массив или чего там. Я считаю, юзать приватные апи такие вещей как j.u.c. вполне нормально и цивильно.

Ну вот предположим вы получили колекцию тредов executor-a, что вы дальше делать то будете? terminate-ить их? Как узнать какой именно нужно? Как узнать что он еще не принялся за обработку следующего запроса из очереди?

[Zorkus]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Им наверное не нужно запускать в бекграунде и стопать запросы выполняющиея часами.

Есть прикольная книжка от инженегров твиттера (meap so far), Big Data называется. Если не читали, советую. Там любопытные вещи пишут об этом в том числе.

А что именно? Описание какого-нибудь асинхронного map/reduce ?

Не, MR/hadoop это все и без них давно описано и реализовано. Там скажу сразу, авторов кое-где заносит и они обобщают свой опыт из твиттера на все large scale projects, и во вторых, они в процессе написания еще, и реагируя на наезды коструктивные комменты на форуме свою книгу правят.

- там интересные есть концепции create-read systems, т.е. где операций изменения и удаления вообще нет, и даются объяснения, каким образом это упрощает построение мастшабируемых систем в смысле CAP theorem (ну там они еще рассказывают про упрощение conflict resolution при восстановалении связи между партишенами и прочим), есть интересное общее описание трехуровневой системы для таких проектов и прочее.
- описываются еще несколько фреймворков типа Thrift для сериализации и перегонки данных.

В общем, я читаю по мере того как они публикают новые главы и им пишу комментарии вот тут: http://www.manning-sandbox.com/forum.js ... 7&start=30

[Zorkus]

А почему геморройно чистить коллекцию ссылок? Наследовали класс ThreadPoolExecutor, там же можете добавить коллекцию ссылок на Runnable. Овверайднули там afterExecute метод и удалили из коллекции переданную вам ссылку на Runnable. Аналогично в beforeExecute можете добавлять Runnable в эту коллекцию. Или я не совсем понял вашу проблему?

Да все правильно, можно конечно и эхтендить ThreadPoolExecutor или научить воркера удалять самого себя из списка. Но ведь блин ThreadPoolExecutor уже хранит этих воркеров в внутренней collection. Вот мне гондурас и не дает покоя по этому поводу. В смысле как до этой collection добраться.

Никак, кроме как через reflections. И не надо добираться - потому что сегодня это коллекция, завтра они в следующей версии Java решат сделать это массивом, а потом, на какой-то хитрой OS, вообще не будут хранить коллекцию, например, потому что у этой OS уже есть родной API для thread pool.

Если единственная проблема автора в том, что нужен доступ к этой коллекции, а злые дизайнеры j.u.c. не открыли ее в паблик, то в чем проблема, через reflection, setAccessible(true) и вперед. Будет работать всегда и без всякого геморроя и оверхеда за исключением двух случаев:

1) прога работает в jvm с суперстрогим security manager, которые не дает дергать через reflection поля. Я в реальности такого не встречал ни разу.
2) в следующем JDK структура этого пуля изменится. Ну и черт с ним, во время апгрейда переписать за 5 минут на массив или чего там. Я считаю, юзать приватные апи такие вещей как j.u.c. вполне нормально и цивильно.

Ну вот предположим вы получили колекцию тредов executor-a, что вы дальше делать то будете? terminate-ить их? Как узнать какой именно нужно? Как узнать что он еще не принялся за обработку следующего запроса из очереди?

Я откуда знаю, я же написал выделено жирным Вообще конечно убивать треды в тред пуле в обход интерфейса этого самого тред пула это ад. Я бы хранил объекты future/callable или как их там, и канселил по мере необходимости.

[Komissar]

а вот я думаю: как же кучу могучих сайтов слабали на PHP и RoR, не заморачиваясь тонкостями многопоточности?

Им наверное не нужно запускать в бекграунде и стопать запросы выполняющиея часами.

Есть прикольная книжка от инженегров твиттера (meap so far), Big Data называется. Если не читали, советую. Там любопытные вещи пишут об этом в том числе.

и какие реальные примеры?
все, что я слышал - от индусов
1. был хороший сайт на ПХП
2. привлек тысячи и тысячи юзеров
3. в какой-то момент стал тормозить, и начальство наняло Великий Индусский Консалтинг (ВИК)
4. ВИК все тщательно проанализировал и рекомендовал все переписать на Джаву с начала и до забора
..
...
....
10. (5 лет прошло) ВИК все еще пасется работает на проекте, но воз и ныне там, а пока для юзеров держат старый ПХП-сайт.

[Интеррапт]

Если единственная проблема автора в том, что нужен доступ к этой коллекции, а злые дизайнеры j.u.c. не открыли ее в паблик, то в чем проблема, через reflection, setAccessible(true) и вперед. Будет работать всегда и без всякого геморроя и оверхеда за исключением двух случаев:

1) прога работает в jvm с суперстрогим security manager, которые не дает дергать через reflection поля. Я в реальности такого не встречал ни разу.
2) в следующем JDK структура этого пуля изменится. Ну и черт с ним, во время апгрейда переписать за 5 минут на массив или чего там. Я считаю, юзать приватные апи такие вещей как j.u.c. вполне нормально и цивильно.

Я заикался про reflection на предидущей - автор ответил, что нет. И это вполне разумно, что нет. Непонятно, как переписывать за 5 минут, если допустим этот код идет как компонента с какой-то библиотекой для вашего кастомера. И он решит апгрейднуть версию Джавы. И все накроется медным тазом. Это не считая того, что нужно каким-то образом помнить, где ты чего через reflection делал и при апргрейде Джавы - инспектировать все свои рефлектные извращения на предмет соответствия.