move metric initialisation upfront connection creation to avoid potential npe #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have a setup where we regularly create a new Memcached client to verify memcached is still running. Now what happens if you totally cut down your network (no LAN & WLAN). You'll get a NPE within MemcachedConnection as the first connection try fails, and then the failure handling tries again trying to increment a metric, which at this time isn't init'd.
This alone wouldn't be too bad if during init a Selector was opened already, which then isn't closed any more. So on mac each time the Selector is opened 2 PIPEs and 1 KQUEUE are created, this leads eventually to a create AF_UNIX socket: Too many open files in system error making the whole system unresponsive.
I've fixed the NPE by moving the metric init to an earlier place, but maybe some try catch around the whole init method would be better to close the all potentially opened handles before bubbling the exception.