[
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)
