[rabbitmq-discuss] Breaking API changes in JAva API 2.7.0

[Steve Powell]

Dear Irmo,
| On 14 Nov 2011, at 10:43, Irmo Manie wrote:
| There is an expectation (at least mine) that the passed in
| ExecutorService on newConnection is managed by the underlying
| connection.
Correct; when the connection goes away the Service will be shutdown.

| On any shutdown signal I see that the ChannelManager does this when
| handling the exception.
Well, it schedules the shutdown, which  happens on another thread.

| There is a problem when connecting to a non-existing host. The
| FrameHandler is created, and throwing a UnknownHostException, before
| the AMQConnection is created and the ExecutorService is 'managed' and
| thus the shutdown of the ExecutorService is left to the user again.
I see, if the connection fails we don't use the ExecutorService. Which
means you are free to use it on another connection attempt.

| You can imagine that this causes a nice leak when you have an
| automatic reconnection setup in place.
I think I see your point.

It might be possible to arrange that we do not shutdown client-supplied
Services, only our own private ones.  Would that be appropriate?
We would then have to relax some of the callback contract on termination.

| Also I noticed that basicConsume still causes the whole connection to
| go down if you throw an exception.
| I know that in previous client versions this was because it was called
| from the connection thread, but I was expected this to be 'fixed' in
| this release because of the separate thread pool for channels.
I presume you mean if you throw an exception in a consumer callback?
The answer is Yes, that is what is supposed to happen, so we didn't
change the behaviour.

We actually call the 
ExceptionHandler.handleConsumerException() method, in general.
And an ExceptionHandler can be set on the AMQConnection constructor.
This parameter is not exposed on the newConnection() (or ConnectionFactory)
interface.  These are all impl classes.

In fact, this whole thread highlights how tricky the ConnectionFactory
interface is. We are minded to deprecate the whole lot and use a Builder
interface instead. This would allow named parameter extensions rather
easily, and make it trivial to explain the interactions between, say, uri()
and host()/port() settings.  We could also add extra parameters without
requiring recoding callers, or adding lots of constructors. It would be
trivial to expose an ExceptionHandler on such an interface.

Let us know your thoughts.

Steve Powell  (a kitten)
----------some more definitions from the SPD----------
Avoirdupois phr. 'Would you like peas with that?'
Abbey adj. Quite like an Abbe.
Definite phr. 'It's hard of hearing, I think.'
Modest n. The most mod.