`activateConnector()` can return null for `RejectedExecutionException`, which causes this appender to terminate, which I think might be premature in some scenarios. I might be wrong, but I think we should continue instead of break.

The `ThreadPoolExecutor` rejects new submissions when either the Executor has been shutdown, or when its pool is at capacity [[1]](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html), assuming the default `ThreadPoolExecutor.AbortPolicy`. Exiting the thread in the former case makes sense to me, but not the latter case. However, if the executor were shutdown, this thread would be interrupted anyway (via `ExecutorService.shutdownNow()`), which is already handled in the while-loop condition, so we shouldn't need to explicitly break for that.

`CoreConstants.MAX_POOL_SIZE` is 32 *per context*. Assuming the same context is used in an application that has several instances of `SocketAppender`, `SocketReceiver`, and `SMTPAppender`, it's potentially possible to fill the thread pool if all appenders are busy sending/receiving (e.g., in a web app). In that scenario, `waitForConnectorToReturnToSocket` could encounter `RejectedExecutionException`, leading to this appender's shutdown, which might not even be noticeable to the user until he eventually detects missing log events and then examines his logback logs from the sending application.