开发者

JMSException - examples of "temporary" troubles that shouldn't trigger reinitialization?

Looking for experiences others might have had. Or JMS spec citations, if you've got them.

Our typical practice when handling a JMSException (in a try/catch or onException() method) is to fully tear down the existing JMS connection/sessions/... and reinitialize them.

A developer asked if we were being too pessimistic. Are there cases we should treat as temporary that will clear themselves? Or is a full tear-down/reinitialize on a JMSException the 开发者_如何转开发best way to go?

I realize this may be somewhat vendor specific. But any wisdom would be welcome.


Sorry for answering my own question. Despite knowing what the JMS spec says about JMSException, I took one last look and was surprised at what I found in in the chapter on JMSException.

I saw the full list of standardized JMS exceptions under JMSException. And plenty of them look like bad API calls or other things not indicating any trouble requiring tear-down/reinitialization. Like InvalidDestinationException (just guessing, no experience yet).

So it sounds like a bit more fine-grained catching (not just JMSException) would allow us to distinguish conditions requiring reinitialization from not. At least in some cases.

Any further thoughts/experiences would be welcome!

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜