Reconsider to move subscriber instantiation outside of the PubSubInboundChannelAdapter.start()

[spring-attic]

Reconsider to move subscriber instantiation outside of the PubSubInboundChannelAdapter.start()

[joaoandremartins]

You showed some concerns on the original PR with doing this kind of low level resource manipulation at Spring initialization time. Do you not feel the same way anymore?

[artembilan]

Well, my point is about distinguishing new Subscriber() and start() if that is possible.
Otherwise I will live with the new instance each time the start() is called.

"level resource manipulation" is a connection to the target service and it really must not happen in the new or in the afterPropertiesSet().
But if Subscriber is robust to stop/start, and is really lightway at the moment of instantiation, we really can move it into the afterPropertiesSet() as one-to-one relationship with enclosing PubSubInboundChannelAdapter.

Does it make sense to you now?

[joaoandremartins]

Yes, I understood you wanted to cache the Subscribers (and possibly the Publishers too?), but MessageProducerSupport doesn't implement afterPropertiesSet().

I'm thinking of checking if the subscriber already exists on doStart(). If it does and is running, do nothing, if it isn't running, start it, if it doesn't exist, create a new one. I'm testing stopping/starting a Subscriber, but running into some deadlocks. Need to investigate more.

[artembilan]

Quoting this issue description:

Therefore Subscriber.defaultBuilder() should be done from the onInit().

That onInit() is called from the super.afterPropertiesSet(). No need to fight with the state in the doStart().

[joaoandremartins]

Starting, then stopping, then starting the same Subscriber doesn't work, since it keeps its internal state and won't restart. I think that's because when Subscriber is closed, it closes all its connections, so there isn't an advantage on restarting the same Subscriber vs just creating a new one.

WDYT @artembilan ?

[artembilan]

Thank you for the investigation, @joaoandremartins !

Closing since it does not make sense work as designed.