Github user dhpatel27 commented on the pull request:
https://github.com/apache/cxf/pull/132#issuecomment-213663398
@cschneider The use case for point-1 mentioned by me above is when the
application wants the flexibility to stop the retries after certain number of
attempts if the Connection couldnt be established to JMS queue managers or JMS
Destinations itself. The client may not like to continue the retry infinite
times due to the CPU Spikes that they can experience unnecessarily after every
completion of thread.sleep. Also, this situation becomes worst if a single JVM
has >50 JMS Destination Listeners defined and a single physical host has
multiple such JVMs. In such scenario, client would still see high CPU when it
continues to do infinite retries. Thus it makes sense to give flexibility to
client in terms of exposing both retries and retryinterval.
Also for point 2, I was trying to avoid need for client to put custom
solution to call explicitly shutdown on JMSDestination as well. ALso, if you
note, shutdown variable is proned to race condition since its not defined
volatile. If you call shutdown from another Thread, and the retry thread is
still looping in another thread, the change in the value of shutdown variable
may not be instantaenously visible to other thread.
Thanks!
---
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.
---
