"HTTPConnectionPool(): Read timed out. (read timeout=0.5)" happends ambiguously

[fasterpython]

As descripted in issue #742 ,
the error below happens frequently:

HTTPConnectionPool(host='localhost', port=44858): Read timed out. (read timeout=0.5)

The flags (in .ycm_extra_conf.py) pass to YCM should be correct, since only some files throw this error but others are OK at the same project.

$ vim ycm_timeout_file.cpp <-- ycm read timed out, but not compile errors in details.
:YcmDiags
Forcing compilation, this will block Vim until done.
No warnings or errors detected

If there are some errors for YCM to compile, error messages should be show out to the user, that's import.

thanks!

[Valloric]

It might be the case that your file is just taking too long to compile, but that should be extremely rare.

Still a duplicate of #742.

[fasterpython]

@Valloric so how about export an option to users to setup time-out value?
As a Ycm user, I think a better working mode is that, Ycm should use double-compile-buffer to do auto-complete jobs.

A-buffer: last time compiled sucessed buffer
B-buffer: currently compiling buffer, might be failed to compile
If B-buffer is failed, then Ycm do auto-complete job using A-buffer.

The reason is, when a user is coding, there might be some errors at the moment, but Ycm shouldn't stop or failed to work at most time.

[snake-ch]

I just change parameter TIMEOUT_SECONDS = 0.5 to 2 in file with path ~/.vim/YouCompleteMe/python/ycm/client/completion_request.py, works well, but why???

[WscriChy]

I have just updated the latest YCM and encountered a lot of this errors. I did what @Tortoisechan said and it worked for me too. Seems like completion is to heavy for the current project, that why it requires sometimes a little more time.

[shinux]

Thanks @Tortoisechan .

[vinceyuan]

My cpp project is just a small project. But I still have the same problem after I work on the cpp project for a while (~20 minutes) and autocomplete becomes unavailable. Changing TIMEOUT_SECONDS does not help, because actually ycm server crashed.
I have to restart ycm server (input :YcmRestartServer in Vim). Restarting Vim also works.

[gauteh]

Solution by @Tortoisechan works for python numpy completions, probably works fine when completions are cached. I think this is a genuine bug. First completions should have longer timeouts or it should be configurable.

[ghost]

So I tried what @Tortoisechan did however I'm still getting the same timeout. It's as if it didn't change at all. Thoughts? HTTPConnectionPool(host='127.0.0.1', port=46668): Read timed out. (read timeout=30)

[ghost]

May be, there's something wrong with firewall.

[gauteh]

I had to use longer than 30 s, it takes shorter time the next time.

Den torsdag 21. juli 2016 skrev Dana3 notifications@github.com følgende:

May be, there's something wrong with firewall.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#777 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADd-9sfEN313AlLgV9-6VTF8CDVdzvkks5qXtcSgaJpZM4BZjb2
.

[ghost]

Yeah I'm unable to set it to higher even after setting the variable to 2. Are there other files that set this parameter? I'm compiling a very large code base

[vheon]

I had to use longer than 30 s, it takes shorter time the next time.

The first time is slower because jedi has to parse all the code. The second time it uses the cached results for the library.

[oblitum]

I had to use longer than 30 s, it takes shorter time the next time.

The first time is slower because jedi has to parse all the code. The second time it uses the cached results for the library.

There's still a worst case scenery which I think is not very uncommon (I've found it in many occasions) which is when there's a lot of matching semantic identifiers in the global namespace and one wants to complete at the global namespace instead of after a trigger, for example:

#include <iostream>
#include <boost/bimap.hpp>

int main() {
    using namespace std;
    using namespace boost;

    c<ctrl-space> // doesn't work mostly
    std:: // works
    boost:: // works
}

Completing at the global namespace is one of the most useful completion features but it seems YCM is not much optimized there, this is even worse in large C codebases where there isn't even a scope operator and one have to deal with names in the global namespace a lot.

Since in this same example completion after scope operator after a namespace works well, but forced completion at global scope barely works, it should be identified whether it's libclang that is being slow at returning the large amount of results that is available at global scope or instead, whether it's YCM/ycmd that's being slow handling this large amount of results (since it may be biased to handle smaller sets that generally show up after triggers). If it's YCM/ycmd to blame, it must be fixed.

[oblitum]

@r4nt's comment on #742 (comment) reinforces what I've just said:

Note that I also see this happening with gocode when triggering completion on large namespaces (fmt. / ioutil.)