Merge branch 'customresource' of github.com:shawkins/kubernetes-clien…

…t into customresource

doc/FAQ.md

@@ -26,7 +26,7 @@ At the core the thread utilization will depend upon the http client implementati
 
 With the JDK http client it will only maintain a selector thread and a small worker pool which will be based upon your available processors per client.  It does not matter how many Informers or Watches you run, the same worker pool is shared.
 
-It is recommended with either http client that logic you supply via Watchers, ExecListeners, ResourceEventHandlers, Predicates, etc. do not execute long running tasks. 
+> **Note:** It is recommended with either HTTP client implementation that logic you supply via Watchers, ExecListeners, ResourceEventHandlers, Predicates, etc. does not execute long running tasks. 
 
 For non-ResourceEventHandlers call backs long-running operation can be a problem.  When using the OkHttp client and default settings holding a IO thread inhibits websocket processing that can timeout the ping and may prevent additional requests since the okhttp client defaults to only 5 concurrent requests per host.  When using the JDK http client the long running task will inhibit the use of that IO thread for ALL http processing.  Note that calling other KubernetesClient operations, especially those with waits, can be long-running.  We are working towards providing non-blocking mode for many of these operations, but until that is available consider using a separate task queue for such work.