JMSException - примеры «временных» проблем, которые не должны вызывать повторную инициализацию?

Question

В поисках опыта, который могли быть у других. Или цитаты из спецификации JMS, если они у вас есть.

Наша обычная практика при обработке JMSException (в методе try / catch или onException ()) - полностью разорвать существующее JMS-соединение / сеансы / ... и повторно инициализировать их.

Разработчик спросил, не слишком ли пессимистично. Есть ли случаи, которые мы должны рассматривать как временные, которые прояснятся? Или полная разборка / повторная инициализация JMSException - лучший путь?

Я понимаю, что это может зависеть от поставщика. Но любая мудрость будет приветствоваться.

Answer 1

Извините за ответ на мой вопрос Несмотря на то, что зная , что JMS спецификация говорит о JMSException, я бросил последний взгляд и был удивлен тем, что нашел в главе о JMSException.

Я видел полный список стандартизированных исключений JMS в разделе JMSException . И многие из них выглядят как неправильные вызовы API или другие вещи, не указывающие на какие-либо проблемы, требующие демонтажа / повторной инициализации. Например, InvalidDestinationException (только догадки, опыта пока нет).

Так что, похоже, что более мелкозернистая перехват (не только JMSException) позволил бы нам отличить условия, требующие повторной инициализации, от не. По крайней мере, в некоторых случаях.

Любые дальнейшие мысли / переживания приветствуются!