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

[Steve Powell]

And, of course, I read the JavaThreadPool implementations again, and we don't
have to shutdown our private ExecutorService when the connection fails, because
if it is not used it allocates no threads, and can be successfully GC'd when we
lose the reference.  Ergo, no leak.

We have to shut it down when we close the connection of course, and we do.

The best solution here is *not* to shutdown the executor service on connection
close *unless it is our own private one*. And to lift the restriction that the
ExecutorService must not be shared between connections.  This then allows the
user to allocate any ExecutorService to the consumer callbacks of a connection,
including sharing a service among several connections.

Let me know what you think.

Steve Powell  (a happy bunny)
----------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.

On 16 Nov 2011, at 15:18, Steve Powell wrote:

> And, of course, I read it again, and we leak our private ExecutorService
> under the connection failure scenario, too.  Well spotted.
> 
> Steve Powell  (a happy bunny)
> ----------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.
> 
>> On 14 Nov 2011, at 10:43, Irmo Manie wrote:
>> 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.
>> 
>> You can imagine that this causes a nice leak when you have an
>> automatic reconnection setup in place.