Improvements on the usage of ContainerProperties and retrying AtomicBoolean

[sobychacko]

Discussed in #132

^{Originally posted by tomazfernandes September 20, 2022}
Hey there! Congrats on the first Milestone!

I have a couple of quick suggestions for your consideration.

In these and a couple of other parts you lookup the ContainerProperties when the Container is already running. Unless I'm missing something, ContainerProperties is a mutable object and users can change those settings at will.

https://github.com/spring-projects-experimental/spring-pulsar/blob/10ef7000a9ab6c28768fa3aa53fb6431b06ea23f/spring-pulsar/src/main/java/org/springframework/pulsar/listener/DefaultPulsarMessageListenerContainer.java#L285-L289

https://github.com/spring-projects-experimental/spring-pulsar/blob/10ef7000a9ab6c28768fa3aa53fb6431b06ea23f/spring-pulsar/src/main/java/org/springframework/pulsar/listener/DefaultPulsarMessageListenerContainer.java#L300-L304

Is a user changing these settings with the Container running a feature? Otherwise, isn't it better to maybe extract these properties to final fields in the inner Listener class when the container starts and look that up instead?

Another part I'm not too sure about is this one:

https://github.com/spring-projects-experimental/spring-pulsar/blob/10ef7000a9ab6c28768fa3aa53fb6431b06ea23f/spring-pulsar/src/main/java/org/springframework/pulsar/listener/DefaultPulsarMessageListenerContainer.java#L456-L458

You seem to be using a concurrency structure in a non concurrency-safe way. If this isn't concurrent code, why not use a plain boolean? Or, if it is concurrent code, isn't the compareAndSet method a better choice, instead of using separate get and set calls?

WDYT, makes sense, or maybe I'm missing something? Thanks!