Проблема с сообщением Java Messaging с сервером Java EE и Glassfish

Question

Я новичок в службе обмена сообщениями Java и не совсем уверен, как все это работает. Я использую JMS с проектом Java EE в NetBeans. Тип сервера, который я использую, - это стеклянная рыба 3. Вот моя ситуация:

У меня есть программа, которая создает два потока: A и B. Эти два потока отправляют сообщения назад и четвертое между eachother через два ресурса сервера Queue, которые я создал , Ниже приведен ряд сообщений, которые предполагают, чтобы быть переданы обратно и четвёртую между А и В.

Что предполагают, чтобы случиться:

1. A is started 
2. B is started 
3. A sends B a message, M1 (producer.send(m1)) 
4. B receives M1 and does some stuff (consumer.receive()) 
5. B sends A a message, M2 
6. A receives M2 and does some stuff 
7. A sends B a message, M3 
8. B receives M3 and does some stuff 

Что происходит на самом деле:

1. A is started 
2. B is started 
3. B receives M3 and does some stuff (consumer.receive()) 

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

Причина, по которой я добавил фиксацию в первую очередь, состояла в том, что одно из моих сообщений, M2, не получалось нитью A. Thread B достигла части своего кода, где он отправил M2 в поток A через производителя .send (M2) (где производитель является объектом MessageProducer). Thread A будет просто зависать на user.receive() (где потребитель - объект MessageConsumer). Я дважды проверил, не отправил ли M2 правильный ресурс очереди, который был.

Answer 1

Я, наконец, понял это. Оказывается, мне нужен session.commit() каждый раз, когда Thread B отправляет сообщение. Кроме того, в моем коде произошла ошибка, и программа закончилась преждевременно, то есть остались сообщения, которые не были получены, и эти сообщения переносятся на следующее время выполнения. То, что я закончил делать, чтобы исправить это просто цикл вокруг consumer.receive (100), пока он не вернул нулевое значение перед началом моих потоков.