DamnWidget/anaconda — pull request #113 by briancline (2014-01-08 08:06:02+00:00)
Title: Fixes hang on Jedi connects that timed out

I haven't narrowed down exactly why this began happening yet, however after having trouble with ST for ~3 days now, have found a fix.

After starting ST3, which resumed a session with about 6 previously open windows, Anaconda would register a local handler, and a few seconds later called `server_is_active` on the worker for it. At that time, ST3 would hang.

As it turns out, Anaconda couldn't connect to the worker it set up, but didn't use a socket timeout for the `server_is_active` check. Without specifying one, this could cause ST3 on OSX to hang for 5 minutes.

Once ST responded after 5mins, the expected 'timed out' exception appeared in the console. Seemed to happen only once at startup no matter how many windows I had open in the session.

At first, to temporarily get around this, I renamed my `~/Library/Caches/Jedi` folder between ST runs to get it to build a fresh caches folder. So something in there created/managed by Jedi seems to be the root cause.

Ultimately, I was able to fix this altogether on the Anaconda side with this addition of a 0.5sec timeout on the socket that `BaseWorker.server_is_active` creates.

`BaseWorker.server_is_healthy` already uses the same 0.5sec timeout, so the assumption of 0.5 seemed safe for checking whether it's simply active.