Re: request/response stuff has broken the java build
On Thu, 2015-01-29 at 12:13 -0500, Rafael Schloming wrote: On Thu, Jan 29, 2015 at 11:42 AM, Andrew Stitcher astitc...@redhat.com wrote: On Wed, 2015-01-28 at 16:09 -0500, Alan Conway wrote: On Tue, 2015-01-27 at 09:46 -0500, Rafael Schloming wrote: Do you have tracing turned on when they time out? With the protocol trace enabled the tests slow down enough that some of them don't finish before the various timeouts kick in. Much more insidious. It turns out that if you use 0.0.0.0 as a connect address AND you have a VPN running AND you are using jython then things hang (at least on fedora 20 in my house in January.) Looking up the ip(7) man page it seems like 0.0.0.0 is only supposed to be used as a bind address, not a connect address, so I switched the tests in question to use 127.0.0.1 and everything works (it also works if I turn off my VPN or use proper python) I didn't switch everything in python to use 127.0.0.1 for connect (NOTE 0.0.0.0 is still correct for listening) in case there was some hidden disaster there. Probably at least the examples and maybe the default port for class Url should be changed, any dissent? I'm curious to know where 0.0.0.0 as a default connect address came from because it should never have worked at all, unless it is handled specially somewhere. I think it's always worked for me, and I'm pretty sure we don't have any special handling for it. I started using 0.0.0.0 since I started working on proton and dispatch, I never used it with qpid c++. Just copying like an idiot. I have a vague impression there was a discussion about it being better. It *is* definitely better on the *server* side, maybe it just spilled over into client side use without careful thought. Looking at the ip(7) man page it does appear to be just plain wrong for use on client. As Rafi said it is not a special proton thing - ssh 0.0.0.0 also works. I guess most TCP stacks treat 0.0.0.0 as 127.0.0.1 but I don't know if there is a standard that says you MUST treat 0.0.0.0 as 127.0.0.1 so maybe it's not a reliable thing to use. Definitely jython does something completely daft on my laptop if VPN is on.
Re: request/response stuff has broken the java build
On Tue, 2015-01-27 at 09:46 -0500, Rafael Schloming wrote: Do you have tracing turned on when they time out? With the protocol trace enabled the tests slow down enough that some of them don't finish before the various timeouts kick in. Much more insidious. It turns out that if you use 0.0.0.0 as a connect address AND you have a VPN running AND you are using jython then things hang (at least on fedora 20 in my house in January.) Looking up the ip(7) man page it seems like 0.0.0.0 is only supposed to be used as a bind address, not a connect address, so I switched the tests in question to use 127.0.0.1 and everything works (it also works if I turn off my VPN or use proper python) I didn't switch everything in python to use 127.0.0.1 for connect (NOTE 0.0.0.0 is still correct for listening) in case there was some hidden disaster there. Probably at least the examples and maybe the default port for class Url should be changed, any dissent? --Rafael On Tue, Jan 27, 2015 at 9:29 AM, Alan Conway acon...@redhat.com wrote: On Tue, 2015-01-27 at 09:00 -0500, Rafael Schloming wrote: Hi Alan, The recently added stuff in utils.py seems to have broken the java build. It uses the 'with' keyword which is apparently not supported in jython. --Rafael Fixing ASAP. I have persistent trouble with the java test failing with timeouts I need to figure that out and stop skipping them :(
Re: request/response stuff has broken the java build
On Tue, 2015-01-27 at 09:00 -0500, Rafael Schloming wrote: Hi Alan, The recently added stuff in utils.py seems to have broken the java build. It uses the 'with' keyword which is apparently not supported in jython. --Rafael Fixing ASAP. I have persistent trouble with the java test failing with timeouts I need to figure that out and stop skipping them :(
Re: request/response stuff has broken the java build
Do you have tracing turned on when they time out? With the protocol trace enabled the tests slow down enough that some of them don't finish before the various timeouts kick in. --Rafael On Tue, Jan 27, 2015 at 9:29 AM, Alan Conway acon...@redhat.com wrote: On Tue, 2015-01-27 at 09:00 -0500, Rafael Schloming wrote: Hi Alan, The recently added stuff in utils.py seems to have broken the java build. It uses the 'with' keyword which is apparently not supported in jython. --Rafael Fixing ASAP. I have persistent trouble with the java test failing with timeouts I need to figure that out and stop skipping them :(
