Menu
▾
▴
Re: [Jython-users] Jython2.7.0 and Pyro4
|
From: John H. <ja...@gm...> - 2015-11-23 22:33:05
|
Hi Jim, That seems like the most sensible option after reviewing your comments and your posts on the bug tracker. Thanks again, John Le 23 nov. 2015 à 17:27, Jim Baker a écrit : > > I believe the safe option for now is to remove socket.SO_EXCLUSIVEADDRUSE - it is only defined on Windows for CPython. It also is not necessary to use when running on Java because Java (since 1.4) implements BSD re-use semantics for sockets when running on Windows; see this bug http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4476378 > > We can review the remaining unsupported options later. > > - Jim > > On Mon, Nov 23, 2015 at 2:14 PM, John Hayes <ja...@gm...> wrote: > Hi Jim, > > Thanks for following up. Yes, I had simply changed that line in my local Pyro4.40 as follows, and it solved the problem I was experiencing: >> if hasattr(socket, "SO_EXCLUSIVEADDRUSE") and socket.SO_EXCLUSIVEADDRUSE >= 0: > > > However, if I'm understanding you correctly that you now believe removing the attribute definitions altogether would not break any other packages maybe that's the best solution to match up with CPython on OS X (I also confirmed your test with Python 2.7.10 on OS X 10.6.8). Then my small patch above would be unnecessary and redundant. > > As a side-note, I actually tried Pyro4.40 with Jython2.5.4rc1 and it failed running the setup.py file. This is not a surprise though as they explicitly state that Pyro only works with Python2.7 and 3.3+: https://pythonhosted.org/Pyro4/install.html#requirements > > Cheers, > > John > > Le 23 nov. 2015 à 15:41, Jim Baker a écrit : > >> John, >> >> I took a look at how Pyro4 specifically uses socket.SO_EXCLUSIVEADDRUSE: >> >> if hasattr(socket, "SO_EXCLUSIVEADDRUSE"): >> sock.setsockopt(socket.SOL_SOCKET, >> socket.SO_EXCLUSIVEADDRUSE, 1) >> >> (https://github.com/irmen/Pyro4/blob/master/src/Pyro4/socketutil.py#L478) >> >> Testing for the existence of attributes to see if they are valid and thereby usable does not work on Jython 2.7 since we raise a socket.error with errno.ENOPROTOOPT if actually used, as you have seen. But in Jython 2.5, such settings are quietly ignored. >> >> So I believe I was wrong to state removing those unsupported attributes would be backwards breaking, because we already broke that with raising the socket.error in 2.7.0. But that change to raising an exception is almost certainly the correct thing to do. It's worth pointing out not defining unsupported attributes is also what CPython does, as we see on a non Windows system (in this case OS X 10.11): >> >> $ python >> Python 2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12) >> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import socket >> >>> socket.SO_EXCLUSIVEADDRUSE >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> AttributeError: 'module' object has no attribute 'SO_EXCLUSIVEADDRUSE' >> socket.SO_EXCLUSIVEADDRUSE >> >> Lastly if I remove socket.SO_EXCLUSIVEADDRUSE from Jython's socket module, most of the Pyro4 test suite passes; otherwise the unit tests stall. Interestingly, the remaining test failures in Pyro4 seem to be good tests for Jython's C-style socket emulation using Netty, specifically around various edge cases seen in closing sockets while data is being sent. >> >> I filed a bug for this problem: http://bugs.jython.org/issue2435 Please comment there or here on this thread if you think I should not remove such unsupported options. >> >> - Jim >> >> >> On Mon, Nov 23, 2015 at 9:20 AM, John Hayes <ja...@gm...> wrote: >> Hi Jim, >> >> First off, thank you and the other Jython developers for the amazing work! I've been using Jython for years in a number of projects and am a big fan. >> >> And thank you for the comments below, I've found the relevant Pyro4 code and come to discover that they removed explicit Jython support in Pyro4.35 (https://github.com/irmen/Pyro4/commit/cb4190ae963f8d41cb68e78350f831724640a180). At least for the problem I was seeing, a one line fix in their code does the trick for now in Pyro4.40 as they were just checking for whether the attribute exists and not whether it also has a valid value (i.e., >= 0). I'll see if they want the patch or if there's a compelling reason not to accept it. >> >> Thanks again! >> >> John >> >> Le 22 nov. 2015 à 22:23, Jim Baker a écrit : >> >>> John, >>> >>> I don't believe that the socket.SO_EXCLUSIVEADDRUSE option (which is exclusive to Windows) is available on Java - not even with Netty, which sometimes reaches into C/JNI to get at lower-level functionality. >>> >>> We have mapped socket constants to negative numbers when they are not supported, per this comment in Lib/_socket.py: >>> >>> # Options with negative constants are not supported >>> # They are being added here so that code that refers to them >>> # will not break with an AttributeError >>> SO_DEBUG = -1 >>> SO_DONTROUTE = -1 >>> SO_EXCLUSIVEADDRUSE = -8 >>> SO_RCVLOWAT = -16 >>> SO_RCVTIMEO = -32 >>> SO_REUSEPORT = -64 >>> SO_SNDLOWAT = -128 >>> SO_SNDTIMEO = -256 >>> SO_USELOOPBACK = -512 >>> >>> This inclusion of constants may incorrectly suggest support, without knowing about this comment, but removing these constants is a backwards breaking change. >>> >>> - Jim >>> >>> On Sun, Nov 22, 2015 at 4:47 PM, John Hayes <ja...@gm...> wrote: >>> Dear all, >>> >>> I'm trying to use Pyro4 with Jython2.7.0. I've installed both 'serpent-1.11' (a Pyro4-dependent serializer) and 'Pyro4-4.40' itself seemingly successfully on Windows 7 using 'jython setup.py install' for the respective source packages. >>> >>> However, if I run this simple example of starting a Pyro server: >>> > import Pyro4 >>> > >>> > class GreetingMaker(object): >>> > def get_fortune(self, name): >>> > return "Hello, {0}. Here is your fortune message:\n" \ >>> > "Behold the warranty -- the bold print giveth and the fine print taketh away.".format(name) >>> > >>> > daemon = Pyro4.Daemon(host="192.168.10.106") # make a Pyro daemon >>> > uri = daemon.register(GreetingMaker) # register the greeting maker as a Pyro object >>> > >>> > print uri # print the uri so we can use it in the client later >>> > daemon.requestLoop() # start the event loop of the server to wait for calls >>> >>> I get the following error: >>> > Traceback (most recent call last): >>> > File "greeting-server.py", line 8, in <module> >>> > daemon = Pyro4.Daemon(host="192.168.10.106") # make a Pyro daemon >>> > File "C:\jython2.7.0\Lib\site-packages\pyro4-4.40-py2.7.egg\Pyro4\core.py", line 901, in __init__ >>> > self.transportServer.init(self, host, port, unixsocket) >>> > File "C:\jython2.7.0\Lib\site-packages\pyro4-4.40-py2.7.egg\Pyro4\socketserver\threadpoolserver.py", line 103, in init >>> > self.sock = socketutil.createSocket(bind=bind_location, reuseaddr=Pyro4.config.SOCK_REUSE, timeout=Pyro4.config.COMMTIMEOUT, noinherit=True, nodelay=Pyro4.config.SOCK_NODELAY) >>> > File "C:\jython2.7.0\Lib\site-packages\pyro4-4.40-py2.7.egg\Pyro4\socketutil.py", line 283, in createSocket >>> > bindOnUnusedPort(sock, bind[0]) >>> > File "C:\jython2.7.0\Lib\site-packages\pyro4-4.40-py2.7.egg\Pyro4\socketutil.py", line 479, in bindOnUnusedPort >>> > sock.setsockopt(socket.SOL_SOCKET, socket.SO_EXCLUSIVEADDRUSE, 1) >>> > File "C:\jython2.7.0\Lib\_socket.py", line 1367, in meth >>> > return getattr(self._sock,name)(*args) >>> > File "C:\jython2.7.0\Lib\_socket.py", line 357, in handle_exception >>> > return method_or_function(*args, **kwargs) >>> > File "C:\jython2.7.0\Lib\_socket.py", line 357, in handle_exception >>> > return method_or_function(*args, **kwargs) >>> > File "C:\jython2.7.0\Lib\_socket.py", line 1204, in setsockopt >>> > raise error(errno.ENOPROTOOPT, "Protocol not available") >>> > _socket.error: [Errno 10042] Protocol not available >>> >>> >>> This seems like a similar problem that someone else was recently having on the mailing list that appears rooted in the call to setsockopt: >>> http://sourceforge.net/p/jython/mailman/message/34127525/ >>> >>> Is this a bug that has already been reported (I couldn't find it), and/or does anyone have any potential ideas for a workaround solution? >>> >>> I really appreciate any help that can be offered! >>> >>> All the best, >>> >>> John >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Jython-users mailing list >>> Jyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/jython-users >>> >> >> > > |
