что заставило бы единственного исполнителя задачи прекратить обрабатывать задачи?

Похоже, вы просто пытаетесь сохранить эти комментарии для последующего использования. Ваше текущее решение состоит в том, чтобы добавить их в строку и использовать токен для создания подстрок? Я не знаком со структурами данных pythons, но это звучит как большая работа для массива или списка в зависимости от того, как вы планируете ссылаться на эти данные.

5
задан Linger 19 July 2012 в 04:27
поделиться

3 ответа

Это кажется, что у Вас есть два других вопроса:

1) Вы перекармливаете очередь заданий. Вы не можете только продолжать наполнять новые задачи в очередь без отношения к норме потребления исполнителей задачи. Необходимо выяснить некоторую логику для знания когда Вы для блокирования новых дополнений к очереди заданий.

2) Любое неперехваченное исключение в потоке задачи может полностью уничтожить поток. Когда это происходит, ExecutorService вращает новый поток для замены его. Но это не означает, что можно проигнорировать любую проблему, заставляет поток умирать во-первых! Найдите те неперехваченные исключения и поймайте их!

Это - просто догадка (cuz существует недостаточно информации в Вашем сообщении для знания иначе), но я не думаю, что проблема состоит в том, что исполнитель задачи прекращает обрабатывать задачи. Мое предположение - то, что это просто не обрабатывает задачи с такой скоростью, как Вы создаете их. (И то, что Ваши задачи иногда умирают преждевременно, является, вероятно, ортогональным к проблеме.)

По крайней мере, это было моим опытом, работающим с исполнителями задачи и пулами потоков.


Хорошо, вот другая возможность, которая звучит выполнимой на основе Вашего комментария (что все будет работать гладко в течение многих часов до внезапного прибытия в отказывающий останов)...

У Вас могла бы быть редкая мертвая блокировка между Вашими потоками задачи. Большую часть времени Вы становитесь удачливыми, и мертвая блокировка не проявляется. Но иногда, два или больше из Ваших потоков задачи входят в состояние, где они ожидают выпуска блокировки, сохраненной другим потоком. В той точке не может произойти больше обработки задачи, и Ваша очередь заданий сложит вплоть до Вас, получают OutOfMemoryError.

Вот то, как я диагностировал бы ту проблему:

Устраните ВСЕ общее состояние между своими потоками задачи. Сначала, это могло бы потребовать каждого потока задачи, делающего защитную копию всех структур совместно используемых данных, которых требуется. После того как Вы сделали это, должно быть абсолютно невозможно испытать мертвую блокировку.

На данном этапе постепенно повторно вводимый структуры совместно используемых данных, по одному (с соответствующей синхронизацией). Повторно выполните свое приложение после каждой крошечной модификации для тестирования на мертвую блокировку. Когда Вы получаете ту ситуацию с катастрофическим отказом снова, внимательно изучаете схемы доступа для совместно используемого ресурса и определяете, необходимо ли действительно совместно использовать его.

Что касается меня, каждый раз, когда я пишу код, который обрабатывает параллельные задачи с пулами потоков и исполнителями, я всегда пытаюсь устранить ВСЕ общее состояние между теми задачами. Что касается приложения, они могут также быть абсолютно автономными приложениями. Выслеживание мертвых блокировок является перетаскиванием, и по моему опыту, лучший способ устранить мертвые блокировки состоит в том, чтобы каждый поток имел свое собственное локальное состояние вместо того, чтобы совместно использовать любое состояние с другими потоками задачи.

Удачи!

10
ответ дан 18 December 2019 в 13:20
поделиться

Мое предположение было бы то, что Ваши задачи блокируются неограниченно долго вместо смерти. Вы имеете доказательство, такое как оператор журнала в конце Вашей задачи, предполагаете, что Ваши задачи успешно завершаются?

Это могло быть мертвой блокировкой или взаимодействием с некоторым внешним процессом, который блокируется.

3
ответ дан 18 December 2019 в 13:20
поделиться

Хотя Вы не оставляете достаточно детали, чтобы быть уверенными, первая вещь, которую я попробовал бы, состоит в том, чтобы иметь Ваши задачи, ловят "Исключение" на верхнем уровне и регистрируют сообщение.

Я знаю, что это не кажется правильным, но иногда (в зависимости от большого количества переменных) я работал над кодом, где материал, происходящий в потоке, выдает исключение, и это никогда не регистрируется, или это просто не обнаруживается на консоли - все же "выполняющиеся" выходы кода из, он - высокоуровневый цикл или независимо от того, что код вызывает Вашу задачу работать.

Я предполагаю, что просто говорю, удостоверьтесь, что Ваши задачи не выдают исключение.

1
ответ дан 18 December 2019 в 13:20
поделиться