thespian.actors.InvalidActorAddress on Mac for multiprocTCPBase #89
Comments
|
Is there an update on this thread? I am getting similar behaviour on a Windows environment. |
|
Apologies: I missed this on the original posting. The initial set of warnings looks to be similar to #11. The error indicates that there is some other process that is running and using port 1900 for communications. Port 1900 is the default port used by the multiprocTCPBase, although a different port can be specified for use (see the 'Admin Port' capability specification at https://thespianpy.com/doc/using.html#hH-9d33a877-b4f0-4012-9510-442d81b0837c). In a linux environment, a command like |
|
I've got a bit more information. To be clear for anyone else hopping on this thread, I'm getting a similar error to the original poster, but my environment is Windows 10 and Python 3.10.8. My code can be seen here. A few more notes on the behaviour I'm seeing
Does anyone know of a reason why thespian would launch a process that listens on the port specified by the capabilities yet reports an InvalidActorAddress error? |
|
I learned some more information. We can easily launch a multiprocTCPBase actor just fine from a wsl environment. The warnings and error are replicated when executed from Windows10 environment (possibly mac as well from the original post) Also, I haven't had any issues with multiprocUDPBase from a Windows environment. Moving forward, does anyone have feedback on these questions?
|
|
Good to hear that it works fine in one environment and we can focus on Windows. The MacOS error in the original port was probably a port conflict that we described previously, which is also indicated by the difference in the error messages, so below I'm focusing more on the Windows scenario you have. The One test would be to see if the following simple scripts can exchange a socket message under your Windows configuration:
Run these two (one each in a pair of terminal sessions, starting the server first) and they should be able to communicate their messages. That will provide a basic verification of the socket communications that Thespian builds on top of. |
|
Great test. Thank you for putting that together. Using the client-server pair directly from the last message, when client tries to run Also worth noting, port 1900 is also being used by svchost.exe which is listening on UDP. That didn't seem to prevent this test from running using port 1900 as long as client's connect command is revised as described |
|
Ah yes, that was my mistake: an empty string corresponds to That confirms that the networking is reasonable. The next thing to check is the thespian internal log (see section 13.3 in the Using Thespian documentation: https://thespianpy.com/doc/using.html#hH-ce55494c-dd7a-4258-a1e8-b090c3bbb1e6). Since you are on Windows, this file will be placed in the Windows temporary location. You might need to increase the maximum size setting, but probably not since this is failing near the original startup. If you can provide that file (here or in a gist) we can see if there's something else Thespian is encountering. |
|
I cleared the log and reran my test 3 times resulting in this file. Note that a different admin port was specified on the third attempt (8084) Note that the log was only made when I invoked the application from a commandline. Nothing is added to the log file if it's invoked through an IDE like pycharm |
|
That didn't provide much, although I forgot to ask you to set the |
|
I ran the following tests (all with
This is the resulting log file: I ralso epeated the tests and got a similar log file with an alternative admin port specified |
|
Regarding the MacOS case,
shows no processes using 1900, but I still get the exception. After this, lsof shows this: |
|
I did some investigation and fixed an issue that might be causing the behaviors observed above. Can you both try pulling the latest Thespian from master and re-run your tests. Also, after you pull, please delete If this does not fix your problems, also note that I've created a If the above fixes your problems, I will cut a new release; if not, I'm hoping we can iterate over updates to the diagnose.py to further identify what is going on in your environments. |
|
Thank you for spending time looking into this. Unfortunately I am still getting the same behaviour with the multiprocTCP Actor System and the latest version of master. I tried running The |
|
I don't have a Windows system to test on unfortunately. That may have been a mis-spelling (the |
|
Any updates from your end, @ProlucidDavid or @neurobs ? |
|
I get the same error as before using master. The diagnose.py log is attached. |
|
Thank you, @neurobs . The logs indicated that a simple client/server socket test is failing in your environment, which may (or may not) be indicative of the root issue for Thespian operations here. I've pushed some additional information gathering to the diagnose.py to try to gather more information. I appreciate your assistance in diagnosing this problem and I hope to find something revealing soon that will help resolve the problems you are seeing. |
|
I'm not seeing any changes to dianose.py on Github, unless I'm doing something silly. |
|
There's not a lot, but it's here: dfc6d3e The previous test seemed to hang somewhere in the socket shutdown, so this just generates a bit more information so I can see where it's happening to start looking for what might be occurring. |
|
I was looking at the wrong repo. |
|
Very odd: that's hanging on the socket.shutdown call. There may be something about those calls on more recent versions of MacOS that is problematic. One thing you could additionally try for me is to comment out that line (line 373 of diagnose.py: Another thing that might be causing issues is the under-configuration of your system that is causing various Please be aware these will make changes on your system so you may decline modifications like this if you are not comfortable with the effects. Again, thank you for working with me on this and I apologize for the prolonged efforts: I no longer have access to a Mac system directly to try these things for myself, but I can say that Thespian worked just fine on a Mac as of approximately 12-18 months ago when I did have a functioning Mac. |
|
I commented line 373 and set the HostName and LocalHostName. |
On MacOS using thespian 3.10.7, the multiprocTCPBase actor system configuration does not work. The exception is as follows:
The Mac firewall is not enabled.
The text was updated successfully, but these errors were encountered: