Модель потоков JBoss и среда выполнения задач Java 5

Question

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

В настоящее время я рассматриваю несколько вариантов.

1. JBoss AS (v7?) С кварцем.
2. JBoss AS (v7?) Только с потоками JBoss
3. Чистая среда выполнения задач Java 5 (ThreadPoolExecutor)

Может кто-нибудь прокомментировать плюсы и минусы этих опций.

Кстати, я также заинтересован в следующем связанном рассмотрении

• Соответствующие достоинства относительно того, как IBM / Sun JDK действительно удается сделать лучшие из многоядерных процессоров. Я планирую работать на IBM или Sun java 7 jvm.
• Независимо от того, использует ли JBoss (и с какой версии) модель потоков java 5.

РЕДАКТИРОВАТЬ Несколько замечаний после доброго ответа Энно Сиоджи.

1. Причина, по которой JBoss на картинке, заключается в том, что данные, хранящиеся в БД, доступны через веб-приложение. Чтобы мой клиент мог спросить: «Почему анализ файла также не выполняется в AS?».
2. Я согласен, что процесс, скорее всего, связан с вводом-выводом, а не с процессором. Однако я очень хочу избежать ситуации, когда плохая логика планирования потоков по всему многослойному ванильному фрагменту os / pthread / jvm / javalib замедлит получение входящих файлов.

Answer 1

JBoss AS - это просто сервер приложений. Если вы не хотите использовать его сервис (например, JMS, WS, EJB, JPA и т. Д.), Вы вообще не будете привлекать JBoss. Это только усложнило бы и, вероятно, замедлило бы.

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

Если вы не выполняете действительно сложные вычисления при анализе ваших файлов, центральный процессор не станет узким местом вашего приложения. Моя (дикая) ставка на то, что это будет доступ к БД. Так что я не буду беспокоиться об эффективности процессора (или о том, на какой JVM работает приложение), если вы не протестируете приложение. и определите, что является узким местом.

UPDATE
О хорошо В этом случае моей рекомендацией будет периодическая проверка с использованием таймера EJB, который отправляет сообщения / задания в JMS с компонентом Message Driven Bean или новым облегченным асинхронным сервисом, который был добавлен в EJB 3.1. Пока вы это делаете (в отличие от создания множества потоков самостоятельно и т. Д.), Я действительно не буду беспокоиться о планировании потоков, потому что JBoss позаботится о правильном дизайне потоков (в первую очередь, сколько потоков будет создано и как делить их между задачами и т. д.).

На самом деле, вы, вероятно, захотите сначала попытаться позволить Timer выполнить всю работу (в отличие от использования причудливого JMS с сервисом MDB / async), если только вы не протестируете и не обнаружите, что он работает недостаточно. Это намного проще и обычно достаточно производительно.

Почти все проблемы с планированием потоков происходят из-за плохого параллелизма (то есть ошибки программиста). Если вы не настроите параллельные вычисления с интенсивным использованием ЦП или что-то в этом роде, я бы не стал беспокоиться о механизме планирования JVM. Это было бы похоже на беспокойство, если мост выдержит, когда вы собираетесь совершить прыжок на банджи оттуда с экспериментальным оборудованием ... (сначала вы должны побеспокоиться об оборудовании)