[jira] [Commented] (CXF-7197) Loop on exception during polling message on JMS queue

["Christian Schneider (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976352#comment-15976352 ] 

Christian Schneider commented on CXF-7197:
------------------------------------------

I propose to use a different solution. The problem with the code above is that it does not handle the case of an Exception because a connection is becoming invalid.
We currently handle the invalid Connection case by adding a exception listener as another fallback. 
Unfortunately exception listener is not supported on all jms providers. 

So I propose to handle all those cases: Transient problem, problem with Session as well as problem with Connection in the same way.

The idea is to exit the polling loop in case of an Exception in session or Connection level and call a callback method provided by JMSDestination. This callback method will do the full restart of the Connection and create a new PollingMessageListenerContainer like the case of the ExceptionListener today.

So we avoid using an Exception listener and do not need additional logic in the PollingMessageListenerContainer that can not handle the Connection case anyway. 
WDYT? 

I will provide a candidate solution in a branch.


> Loop on exception during polling message on JMS queue
> -----------------------------------------------------
>
>                 Key: CXF-7197
>                 URL: https://issues.apache.org/jira/browse/CXF-7197
>             Project: CXF
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 3.1.4
>         Environment: CXF 3.1.4, Weblogic 12c, Soap over JMS
>            Reporter: Jérôme Tamborini
>            Assignee: Freeman Fang
>              Labels: exception, jms, security
>             Fix For: 3.2.0
>
>
> Hi, 
> when an exception occurs (in my case JMSSecurityException) during PollingMessageListenerContainer$Poller#run(), it loops at CPU speed and write exception stacktrace in log. This makes the logfile grows very fast and can make the hard drive full on server.
> I can propose a PR (If I got the rights on Fisheye) which is working with the commit related to CXF-6742.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)