|
From: John H. <ja...@gm...> - 2015-11-22 23:48:06
|
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
|
|
From: Jim B. <jim...@py...> - 2015-11-23 03:24:25
|
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
>
|
|
From: John H. <ja...@gm...> - 2015-11-23 16:20:42
|
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 > |
|
From: Jim B. <jim...@py...> - 2015-11-23 20:42:10
|
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
>>
>
>
>
|
|
From: John H. <ja...@gm...> - 2015-11-23 21:14:39
|
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 >> > > |
|
From: Jim B. <jim...@py...> - 2015-11-23 22:27:32
|
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 >>> >> >> >> > > |
|
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 >>> >> >> > > |
|
From: Jim B. <jim...@py...> - 2015-11-23 22:47:08
|
Sounds good, I removed socket.SO_EXCLUSIVEADDRUSE and this change will be part of Jython 2.7.1. See https://hg.python.org/jython/rev/f528d540f4b3 On Mon, Nov 23, 2015 at 3:32 PM, John Hayes <ja...@gm...> wrote: > 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 >>>> >>> >>> >>> >> >> > > |