Github user dhpatel27 commented on the pull request:
https://github.com/apache/cxf/commit/5e3ac2b252412b90d6c91dea855773a294c3a565#commitcomment-17201043
In
rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java:
In
rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSDestination.java
on line 182:
@cschneider #2 Problem mentioned in CXF Bug CXF-6454, I think we should
still try to get rid of infinite loop problem as well. We are trying to give a
feature of maxRetries as well so that customers can configure on their own as
per their needs. Thus, I would still suggest we put a loop controller with
maxRetries as in the original code from @vikash32504. Further there are 2
problems in addition
1. If a thread interrupts the loop, you are not cleaning up the resources
done in method deactivate(). It simply is coming out without cleaning up the
resources.
2. We are still not giving control to the customer using this feature to
control the maxRetries and coming out of the loop without interrupting the
thread.
3. Also, in addition to that, Thread.sleep() should be put in try block
before deactivate as done in original commit by @vikash32504 since it does not
make sense to retry immediately the JMS Connection. Thread.sleep will allow a
grace period for Queue Mgr to come up and thus, we should keep Thread.sleep
before deactivate and put maxRetries back in loop to come out of the endless
loop
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
