Connection Refused (Win 7 Pro x64)

[bryan-lott]

Receive the below when starting up ST3 (Build 3035). Installed SublimePythonIDE through package control successfully. Response seems to be very slow (after starting to type "import" ST3 seems to freeze for ~10 seconds).

Am on Win 7 Pro x64 w/ Sublime Text 3 Build 3035 x64. Have Python 2.7.4 installed. Please let me know if you need any additional info.

[snip ~20 lines or so of similar output] starting server on port 62040 with python starting server on port 62017 with python starting server on port 62023 with python starting server on port 62029 with python starting server on port 62035 with python [/snip] Traceback (most recent call last): File "C:\Users\bryan.lott\AppData\Roaming\Sublime Text 3\Packages\Python IDE\sublime_python.py", line 86, in send_heartbeat self.proxy.heartbeat() File "X/xmlrpc/client.py", line 1090, in call File "X/xmlrpc/client.py", line 1419, in __request File "X/xmlrpc/client.py", line 1132, in request File "X/xmlrpc/client.py", line 1143, in single_request File "X/xmlrpc/client.py", line 1255, in send_request File "X/xmlrpc/client.py", line 1285, in send_content File "X/http/client.py", line 1045, in endheaders File "X/http/client.py", line 890, in _send_output File "X/http/client.py", line 828, in send File "X/http/client.py", line 806, in connect File "X/socket.py", line 424, in create_connection File "X/socket.py", line 415, in create_connection ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it

[DamnWidget]

Can you check if those server processes exists on the system? (they should be Python standalone applications)

[notlegos]

Am having the identical issue (I won't copy and paste the console output since it's the same), and was able to somewhat hack things into submission by:

1. Manually running the server, i.e. >python server.py 1234
2. Modifying lines 71-73 of sublime_python.py as such:

print("starting server on port %i with %s" % (1234, self.python)) self.proxy = xmlrpc.client.ServerProxy( 'http://localhost:%i' % 1234, allow_none=True)

After doing this, it seems to at least partilly work, for instance typing print pops up with (builtin, function), but it is still quite slow with about a 1sec. delay and some console chatter:

starting server on port 1234 with python Traceback (most recent call last): File "***\Sublime3\Data\Packages\SublimePythonIDE-master\sublime_python.py", line 86, in send_heartbeat self.proxy.heartbeat() File "X/xmlrpc/client.py", line 1090, in call File "X/xmlrpc/client.py", line 1419, in __request File "X/xmlrpc/client.py", line 1132, in request File "X/xmlrpc/client.py", line 1144, in single_request File "X/http/client.py", line 1123, in getresponse http.client.ResponseNotReady: Idle

This is on win7x64 w/ python 3.3.1 x64. Not sure why SublimePythonIDE is struggling with launching the server, but I'd be happy to troubleshoot. Please advise :-) If I wasn't getting Sublime set up to literally do my first "hello world" in Python I'd take a stab at it...

[DamnWidget]

Hopefully I can spend some time with a Win7 x86_64 VM today to try to reproduce this one

[DamnWidget]

Hi @mystickphoenix and @MrMusto ,

Your problem is related with Windows7 firewall configuration. What you have to do is click on Start->Control Panel->Security and System->Allow a program through Windows Firewall (Idk if the names of the menus are the same, my Windows is in Spanish)

Then click on Modify Configuration and search for "python" click in both private and public, Acept and your problem should be gone.

If you still experience the same problem just add ST3 and ST3 plugin_host doing click in "Allow another program" and looking for it.

Anyway, I experienced crashes in the processes that SublimePython starts in order to execute Rope in your Python interpreter (even in my twisted branch) so I'm not really sure what's going on there as I am not really a Windows user so I'm not skilled on Windows internals at all.

Btw I was shocked about how slow is working ST3 on Windows compared with Linux (I didn't check on Mac).

Regards.

[notlegos]

Hi @DamnWidget,

Thanks for suggesting to look into the Firewall settings to see if that can resolve things. Like you I also am primarily a Linux user, but I was hoping to get this going on a windows system that's part of a domain. Mandatory group policy settings make it so that I can't rule out a Firewall issue, so at some point I'll see if I can reproduce this problem in VirtualBox. This very well may be a firewall issue, but if it is, I will probably try to find an alternative to creating a firewall exception since that is not an option for me :-) If I succeed then I will be sure to report back!

[OscarL]

I have the same issue on WinXP. Adding a Firewall exception did not fixed the issue (I've tried adding exceptions for "python.exe", "plugin_host.exe", and "sublime_text.exe"). A real bummer.

[bryan-lott]

I've added python, plugin_host, and sublime_text to the firewall's allow and still have the same behavior. I am on a domain here at work if that helps any.

[JulianEberius]

Hi,

Sorry to hear about your problems. I don't use Windows myself, so I never tested the plugin on it. I'll try to find some time, but I'll need a Windows VM with ST3, Python, etc.. So it's nothing I can do quickly/on the fly.

Julian

[bryan-lott]

Had a feeling that this one might be a pain/take a long time to fix. No worries. I develop on ST3 for python without a lot of plugins. Was hoping yours would work and make life a bit easier :)

[OscarL]

According to @t4ec's traceback in #14, this same error can happen on OSX, and @dskinner's comment seems to suggest the same for Linux.

I've just installed Python 2.7.5 and ST3 (build 3047) on a fresh Windows XP installation. Installed Package Control, and from there, "Python IDE".

Created a new project, added a folder to it ("C:\Code"), edited the project to add: "settings": {"python_interpreter": "C:\Python27\python.exe"}.

Created a new file, saved it as test.py inside C:\Code, opened up Sublime's console, just to see those "ConnectionRefusedError" [WinError 10061] messages fly by.

Seeing the same tracebacks from a user running OSX gives me a little bit of hope in @JulianEberius being able to find the source of the problem.

[JulianEberius]

Hi,

I just pushed a new branch "server_debugging". If you are still interested, check out this branch and set the flag SERVER_DEBUGGING (line 27 in sublime_python.py) to True.

Hopefully, SublimePythonIDE will then start to print the server's stderr to ST3's console and we can diagnose the problem.

Julian

[bryan-lott]

This is all I got from the console (looks pretty similar to my prior output), hopefully someone else gets more info back:

Traceback (most recent call last): File "C:\Users\bryan.lott\AppData\Roaming\Sublime Text 3\Packages\SublimePython\sublime_python.py", line 148, in send_heartbeat self.proxy.heartbeat() File "X/xmlrpc/client.py", line 1090, in call File "X/xmlrpc/client.py", line 1419, in __request File "X/xmlrpc/client.py", line 1132, in request File "X/xmlrpc/client.py", line 1143, in single_request File "X/xmlrpc/client.py", line 1255, in send_request File "X/xmlrpc/client.py", line 1285, in send_content File "X/http/client.py", line 1045, in endheaders File "X/http/client.py", line 890, in _send_output File "X/http/client.py", line 828, in send File "X/http/client.py", line 806, in connect File "X/socket.py", line 424, in create_connection File "X/socket.py", line 415, in create_connection ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it

[JulianEberius]

Very strange. I pushed another change to (to the server_debugging branch) that makes it even more verbose. If you have the correct branch and set the SERVER_DEBUGGING flag then it should now at the very least print

started server on port xyz with python IN DEBUG MODE

The first thing the server sends should look like:

Server on port xyz - STDERR: b'SublimePythonIDE Server is starting in Debug mode\n'

[bryan-lott]

w/ debug flag set:

starting SublimePythonIDE server started server on port 51780 with python IN DEBUG MODE [snipped bunch of started] Server on port 51797 - STDERR: b"python: can't open file ''C:\Users\bryan.lott\AppData\Roaming\Sublime': [Errno 22] Invalid argument\r\n" Traceback (most recent call last): File "C:\Users\bryan.lott\AppData\Roaming\Sublime Text 3\Packages\SublimePython\sublime_python.py", line 151, in send_heartbeat self.proxy.heartbeat() File "X/xmlrpc/client.py", line 1090, in call File "X/xmlrpc/client.py", line 1419, in __request File "X/xmlrpc/client.py", line 1132, in request File "X/xmlrpc/client.py", line 1143, in single_request File "X/xmlrpc/client.py", line 1255, in send_request File "X/xmlrpc/client.py", line 1285, in send_content File "X/http/client.py", line 1045, in endheaders File "X/http/client.py", line 890, in _send_output File "X/http/client.py", line 828, in send File "X/http/client.py", line 806, in connect File "X/socket.py", line 424, in create_connection File "X/socket.py", line 415, in create_connection ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it

[OscarL]

Alright... Now I get the following:

started server on port 1790 with C:\Python27\python.exe IN DEBUG MODE Server on port 1790 - STDERR: b"C:\Python27\python.exe: can't open file ''C:\Documents': [Errno 22] Invalid argument\r\n"

The rest is the usual traceback ending in:

File "X/socket.py", line 424, in create_connection File "X/socket.py", line 415, in create_connection ConnectionRefusedError: [WinError 10061]

No idea as to what it is trying to open under C:\Documents (I suspect i should be "C:\Documents and Settings")...

[bryan-lott]

It looks like it's failing on the spaces in the file path...

[OscarL]

Yup. Properly quoting the parameters to subprocess.Popen (in Proxy's restart method) reveals that SERVER_SCRIPT is also wrong:

It tries to call: "C:\Documents and Setting[...]\Packages\Python IDE\server/server.py" (I've just added that [...] to avoid writing the full path).

[bryan-lott]

managed to get it to not die on the server bit:

[line 105] import shlex args = shlex.split("%s %s %i 1" % (self.python, SERVER_SCRIPT, self.port)) self.proc = subprocess.Popen(args, shell=True, stderr=subprocess.PIPE)

[JulianEberius]

I've (hopefully) fixed the SERVER_SCRIPT definition to correctly use os.path.join, to produce the strange backslash for Windows ;-), and have added the shlex.split to the argument definition of the server subprocess. shlex.split is even in the official subprocess documentation, I just read about it now... sorry! Always worked for me as a simple string ;-)

I have no Windows VM with ST3 at hand, so feedback is appreciated. I've only commited the changes to the server_debugging branch for now. Will merge them into master if it works for you.

[olegpidsadnyi]

I'm having the same problem on the OS X (10.8.4). It works in the debug mode if i start the server externally, but refuses the connection if the server is started with the ST3. I added all binaries from the ST3 bundle to the firewall, but it doesn't work :( How do you run it on the OS X? Doing anything special with the firewall? Is it possible to let ST3 use the system python3 and maybe allow the incoming connections this way?

[OscarL]

I've just added a comment on commit 89037b7797b6a1b4f06e6395376e966efc787d0b as to why it still won't work on Windows (the arguments to Popen must be surrounded with double quoutes if they contain spaces).

I've made a comment here yesterday (it seems to be gone now, weird), I've made it work by removing the use of pipes.quote(), and making the call to Popen look like this:

self.proc = subprocess.Popen('"%s" "%s" %i' % (self.python, SERVER_SCRIPT, self.port), shell=True)

Note that the documentation for the pipes module states: "Platforms: Unix"

[JulianEberius]

I've commited this fix on the server_debugging branch. It starts up on Windows and OSX for me now, but the connection on Windows is still shaky and slow. Sorry, but I don't think I can support this plugin on Windows, I just don't have the time to deal with it. If anybody finds a way to make it run fast on Windows I'm happy to accept pull requests.

[bryan-lott]

Since I mainly develop on Windows, I'll see if I can get some time to take a look soon. I've never worked with python in the ST api though. One basic question, is there any way to run a profiler on the plugin in ST3?

[JulianEberius]

Python has a built-in profiler which I used to optimize Rope's completion engine, see server/server.py@profile_completions.

I'm not sure how well this will work for this new problem, as it's all happening in ST3 API callbacks and, my guess is, in Pythons Windows-HTTP and -Socket modules communicating with the server. But you can give it a try. On POSIX systems the statistics file generated with Python's profile module can be visualized with

gprof2dot -f pstats SublimePython.stats | dot -Tpng -o output.png; 

As seen described here: http://stackoverflow.com/a/843725 . Maybe there is a similar tool on Windows. Python profiler docs: http://docs.python.org/2/library/profile.html

Good luck ;-)

[bryan-lott]

Thanks! I have a feeling I'magonna need it ;)

[bryan-lott]

Just wanted to add that I've made 0 progress on this and don't see much room for making any. Basically, I'm passing it back your way Julian. Sorry!

[asfaltboy]

If I may chip in, I'm also running Windows 7 x64 and after a few minor fixed (#27) I've managed to stop the random crashes I'm having, and I'm quite pleased with how the plugin works now.

Also, performance wise, for me it seems to work quite well (almost without any slowdowns). No sure what fixes that, but the major slowdowns I had were when the plugin attempted to open (and in the same time connect to) the proxy servers at invalid interpretor path (hence the fix). I had to also make sure to write the path with forward slashes like so: c:/Python27/python.exe

[JulianEberius]

I've pushed a new branch called "windows", which is based on current master (it includes the linter merge), but also includes fixes from the server-debugging branch, from asfaltboy (#27) and some more that I made just now. It should hopefully reliably detect the system python path both on Posix and Windows, or use the path given by the user while correctly terminating and throwing an exception if it can not detect the path, or not start the server with the given/detected path.

Even though it's called "windows" please also test it on Linux if you have some time. Its the most current version of the plugin and will be merged back into master if it works for me for a couple of days ;-) If it works on Windows, even better.

[bryan-lott]

Things are MUCH better now. Still getting slowdown every once in a while along with some tracebacks in the console: Traceback (most recent call last): File "C:\Users\bryan.lott\AppData\Roaming\Sublime Text 3\Packages\SublimePythonIDE\sublime_python.py", line 153, in send_heartbeat self.proxy.heartbeat() File "X/xmlrpc/client.py", line 1090, in call File "X/xmlrpc/client.py", line 1419, in __request File "X/xmlrpc/client.py", line 1132, in request File "X/xmlrpc/client.py", line 1143, in single_request File "X/xmlrpc/client.py", line 1248, in send_request File "X/http/client.py", line 932, in putrequest

Also: SublimePythonIDE: No server respose 'NoneType' object has no attribute 'data'

[OscarL]

I've just made a quick test with the "windows" branch on XP... does not works. There is no "where" command on WinXP that I know of, and that's what I'm getting, a FileNotFoundError from the "system_python()" function.

It finds it if we use:

sys_py = subprocess.check_output('python -c "import sys; print sys.executable"', creationflags=CREATION_FLAGS)

(and I guess that it should work on other platforms as well).

Still, it doesn't works, more connections refused, and using the SERVER_DEBUG flag doesn't help: SublimeText's console gets flooded with error messages from the Queue:

"<bound method Queue.get of <queue.Queue object at 0x01B846F0>>"

I'll try to narrow it down and report back (I have a slightly modified version of the server_debug branch that works OK on all my WinXP machines).

[OscarL]

Ok, after fixing system_python() (see previous comment), all I need to do to make it work is to call Popen passing it the "cwd" parameter set to the dirname of the system_python(), ie:

Changing line 114 from:

self.proc = subprocess.Popen(proc_args, creationflags=CREATION_FLAGS)

To this:

self.proc = subprocess.Popen(proc_args, cwd=os.path.dirname(self.python), creationflags=CREATION_FLAGS)

I'm not creating a pull request just yet, because I don't know if that will affect Linux/OSX.

Where was the problem in WinXP? For some reason the Python interpreter (that runs the server) was picking SublimeText's "python33.dll", instead of loading (in my case) python27.dll from C:\WINDOWS\system32 (that's where it ends with an official Python installer).

[JulianEberius]

Haha, I even read that the "where" command only exists from Windows Server 2003 onward. I just thought: "Python developers do not use Windows XP anymore", sorry. Your solution is probably better, although I think it needs "shell=True" or it won't find "python" at least on POSIX...

I'll try both changes and commit them later to the "windows" branch.

[JulianEberius]

I have pushed changes from the windows and server_debugging branch to master. It was stable for me for a couple of days and seemed to work on windows in a 5-minute test :-) Please update via git/Package Control and check if it works for you.

[Stieffers]

I'm on the master branch on Win7 x64 and I'm experiencing the same slowdowns as everyone else has experienced previously. I also tried the server_debugging and windows branches and was coming up with the same errors everyone else has mentioned on here. The only debugging I'm seeing in the console on the master branch is as follows:

Traceback (most recent call last): File "C:\Users\Taylor Stieff\AppData\Roaming\Sublime Text 3\Packages\SublimePythonIDE\sublime_python.py", line 162, in send_heartbeat self.proxy.heartbeat() File "X/xmlrpc/client.py", line 1090, in call File "X/xmlrpc/client.py", line 1419, in __request File "X/xmlrpc/client.py", line 1132, in request File "X/xmlrpc/client.py", line 1144, in single_request File "X/http/client.py", line 1123, in getresponse http.client.ResponseNotReady: Idle

Edit: And with server_debugging = True it's the same output

[aWakeParks]

Are there any news on this issue, it has been quite a while since the last post? I am new to python programming and would really appreciate to use this plugin on Windows.

I have exactly the same bug on Windows 8.1 x64

started server on port 50832 with C:\Python27\python.exe Traceback (most recent call last): File "C:\Users\Peter\AppData\Roaming\Sublime Text 3\Packages\SublimePythonIDE\sublime_python.py", line 170, in send_heartbeat self.proxy.heartbeat() File "./xmlrpc/client.py", line 1090, in call return self.send(self.name, args) File "./xmlrpc/client.py", line 1419, in request verbose=self.verbose File "./xmlrpc/client.py", line 1132, in request return self.single_request(host, handler, request_body, verbose) File "./xmlrpc/client.py", line 1144, in single_request resp = http_conn.getresponse() File "./http/client.py", line 1139, in getresponse raise ResponseNotReady(self.__state) http.client.ResponseNotReady: Idle

I would love to help fixing this, if somebody want's me to run or log anything let me know.

[asfaltboy]

@aWakeParks have you tried adding an exception to your firewall as explained above (allow python.exe and sublime_text.exe)?

Also, after seeing the line "started server on port 50832", please run netstat -aon | more in cmd and see if 50832 appears in the Local Address column, and if so that the PID belongs to sublime.

Also, please give some more details on the issue you are experiencing: does work for a while then stop? Or are you experiencing slowdowns? Or another symptom?

[aWakeParks]

@asfaltboy

I set up the firewall to allow access for python and sublime. Didn't help unfortunately.

Here is what happens as soon as I start SublimeText with SublimePythonIDE package enabled.

1. I open a python file and as soon as I write something, the console starts the server.
2. There is a 5 second lag and the python error from above is drawn to the console.
3. Then there is another lag, and as soon I can type again, step 2 starts over again.

Step 1 in detail:

started server on port 49268 with C:\Python27\python.exe

TCP 127.0.0.1:49268 0.0.0.0:0 ABHÖREN 7500 = listening TCP 127.0.0.1:49268 127.0.0.1:49284 WARTEND 0 = waiting

Step 2 in detail:

Traceback - thrown same message as in my previous post. corresponding cmd netstat entries: TCP 127.0.0.1:49268 127.0.0.1:49481 WARTEND 0 = waiting TCP 127.0.0.1:49268 127.0.0.1:49483 WARTEND 0 TCP 127.0.0.1:49268 127.0.0.1:49515 FIN_WARTEN_2 7500 = fin?_wait TCP 127.0.0.1:49268 127.0.0.1:49519 WARTEND 0

Step 3 in detail:

new server is starting: started server on port 49565 with C:\Python27\python.exe

old server entries in cmd netstat disappeared: TCP 127.0.0.1:49565 0.0.0.0:0 ABHÖREN 5620 = listening TCP 127.0.0.1:49565 127.0.0.1:49580 WARTEND 0

So basically it works for a few moments but then it breaks. I just also found out that once the PID changes, sometimes it's python.exe sometimes a random number i couldn't find in the task manager or running tasklist via cmd.

[bitstream9]

This bug actually has two separate issues:

XML-RPC sometimes fails

This is caused by using the same xmlrpclib.ServerProxy objects in multiple threads. For instance, heartbeat() and completions() use it in different threads. In this situation, two XML-RPC calls are potentially made at nearly the same time, which causes a httplib.HTTPConnection to be interrupted by an intervening 'request' operation at some time. However, we know that each httplib.HTTPConnection.request must be paired with a .getresponse() call. If that pairing is interrupted by another request operation, the second request will produce the CannotSendRequest error. You can refer to this stackoverflow page for details.

To resolve this problem, one way is to set up different xmlrpclib.ServerProxy for different threads. Another way is to set up a lock for each Proxy object. The lock is acquired before each XML-RPC calls and is released after the call finishes.

I found that after setting up locks, the calls don't fail any more. However, the calls are still quite slow. This is caused by the second issue:

Extremely slow XML-RPC

As another stackoverflow page shows, seems that the root cause is that it is quite slow to resolve the address of localhost on windows. The solution is quite simple: just replace 'localhost' with '127.0.0.1' in sublime_python.py.

After making these changes, the speed looks quite reasonable.

I have pasted my changes at http://pastebin.com/99X0zXuh. Give it a shot if you are interested. Note:

1. on some computers, localhost may not be '127.0.0.1', so it's better to resolve the address of localhost in the python script instead of hard coding it; 2. it still remains to discuss whether it's better to use different proxies for different threads or setting up locks.

[aWakeParks]

@bitstream9 wow thanks. Overwriting the sublime_python.py with yours makes it stable and as you suggested it even feels a lot faster.

I appreciate the in-depth explanation on the issues and I can understand why it wasn't working before. As already said in my first post, it's just too early for me to try and change the xmlrpc server to open serveral calls each with its own proxy just to see what benefits or disadvantages it would result in.

I would recommend adding bitstreams changes to a new windows branch or even merge it to the master branch, if it's stable on other platforms as well.

[JulianEberius]

Original author here... Wow thanks @bitstream9 for your detailed investigation into these problems!

I think the lock-based solution should be ok, we do not have a lot of request in parallel, and I guess the server, which is a very basic standard library XML-RPC server, probably processes them serially anyway. I have implemented it a bit simpler though.. it should actually be ok to just acquire the lock in getattr of the Proxy class, as this is the only place where client methods are actually called, the rest is just indirection.

About the "localhost" vs. "127.0.0.1" issue: the resolving of the localhost can be done once upon initialization of the Proxy object... this should work just as well, but also work on computers where localhost does not resolve to 127.0.0.1 .

I have commited a new version of the plugin that incorporates these fixes. Maybe some windows users can report back whether the issue is fixed for them after updating.

Thanks again, Julian

[bitstream9]

Great! Locking in getattr is indeed simpler and more elegant.

Since I am traveling, I just tested it for a few minutes. So far, so good. I will test it more carefully when I go back next week.

Thanks!

[JulianEberius]

The plugin should be much more stable and faster on Windows with the recent changes. I'll close this issue since nobody reported issues since then. Feel free to reopen (or open a new issue) if there are more connection issues.