Но почему вы не хотите, чтобы поток OnMessage ждал, когда вы завершите свою работу? Это в значительной степени цель системы обмена сообщениями. Если вам не удастся вставить в БД из-за какой-либо ошибки, сообщение будет откатано и не потеряно - и может быть предпринята вторая попытка. Если вы перегрузите работу логики / базы данных в другом месте, вы потеряете отказоустойчивость.
В любом случае, лучший способ - не порождать потоки или аналогичные из OnMessage, а помещать сообщение в некоторую внутреннюю очередь, которую вы читаете работающими потоками. Если вы просто раскручиваете потоки, у вас будет проблема с обработкой, скажем, нескольких тысяч сообщений в очереди при запуске. Для этой цели у Java есть BlockingQueue . Таким образом, вы можете контролировать, сколько потоков должно быть занято логикой / базой данных. Вам нужно где-то установить предел, сколько сообщений вы можете прочитать из ActiveMQ, прежде чем вам нужно будет ждать, пока бэкэнд не успеет. Хорошим способом сделать это является очередь.
Пример с очередью блокировки.
final BlockingQueue<String> internalQueue = new ArrayBlockingQueue<String>(CAPACITY);
...
new Thread(new Runnable() { // TODO make a named class and schedule as many thread as needed.
@Override public void run() {
try {
while (true) {
String msg = internalQueue.take();
System.out.println(msg);
}
} catch (InterruptedException e) {
System.out.println("Interrupted.");
}
}
}).start();
...
public void onMessage(Message message) {
if (message instanceof TextMessage) {
internalQueue.put(((TextMessage)message).getText());
}
}
В любом случае, если подумать об этом в другой раз, не лучше ли в любом случае просто сохранить очередь в ActiveMQ? Если процесс занимает слишком много времени, рассмотрите возможность разбиения потока на несколько этапов с очередями между ними.
Пример:
- очередь -> проверка / проверка ошибок -> очередь -> массовая логика -> очередь -> постоянное хранение базы данных -> очередь -> уведомления