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!
精彩评论