[jira] [Commented] (PROTON-949) proton doesn't build with ccache swig

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998697#comment-14998697
 ] 

ASF subversion and git services commented on PROTON-949:


Commit e17c4abf20db1a50620973821022561f6dfb44f9 in qpid-proton's branch 
refs/heads/0.11.x from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e17c4ab ]

PROTON-949: fix proton build with ccache swig

Moved macro calls and preprocessor directives out of %inline sections, seems to 
fix the problem.

NOTE: According to ccache-swig man page: "Known problems are using
preprocessor directives within %inline blocks and the use of ’#pragma SWIG’."
This includes using any macros in an %inline section.


> proton doesn't build with ccache swig
> -
>
> Key: PROTON-949
> URL: https://issues.apache.org/jira/browse/PROTON-949
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: michael goulish
>Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> Thanks to aconway for finding this and saving me a day of madness and horror.
> On freshly-downloaded proton tree, if I use this swig:
>/usr/lib64/ccache/swig
> the build fails this way:
>   qpid-proton/build/proton-c/bindings/python/cprotonPYTHON_wrap.c:4993:25: 
> error: 'PN_HANDLE' undeclared (first use in this function)
> PNI_PYTRACER = *((PN_HANDLE *)(argp));
> --
> but if I delete that swig executable, and use the one in  /bin/swig ,
> then everything works.
> yikes.
> aconway believes the bug is in ccache-swig, not in proton, but I want to put 
> this here in case this bites someone else in Proton Land.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton 0.11.0 release update - The release candidate

[Justin Ross]

Something came up at work, so I'm delaying RC 2 to tomorrow morning.

On Mon, Nov 9, 2015 at 1:26 PM, Justin Ross  wrote:

> Okay, I don't object to a respin to pick this up.  If anyone else does,
> speak up.  Alan, please line up a reviewer to comment on PROTON-949.
>
> Take notice!  Last call: I'm going to spin for RC 2 tomorrow and start the
> vote shortly after.  If you are aware of any problems, speak now.
>
> Thanks,
> Justin
>
> On Mon, Nov 9, 2015 at 10:59 AM, aconway  wrote:
>
>> On Tue, 2015-11-03 at 22:15 -0500, Justin Ross wrote:
>> > Hi, all.  The RC is now available here:
>> >
>> >   https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-rc/
>> >
>> > Maven staging repo:
>> >
>> >   https://repository.apache.org/content/repositories/orgapacheqpid-10
>> > 48/
>> >
>> > I will be away from my keyboard for the remainder of this week.  On
>> > Monday,
>> > the 9th, I will start the release vote if no blockers have been
>> > discovered
>> > in the interim.
>> >
>> > Thank you very much to everyone who tested the alpha and beta.  If
>> > you've
>> > not yet taken a look, please test the RC and report your results.
>> >
>>
>>
>> https://issues.apache.org/jira/browse/PROTON-949 is not in the RC. It
>> is not a regression but it is a *very* perplexing build failure with a
>> very low risk fix, IMO we should get it in there.
>>
>> Not only is it very hard to figure out why it won't build, but when you
>> finally fix the problem by removing the ccache swig binary, it
>> magically comes back when swig happens to get auto-updated by
>> yum/dnf/whatever and you waste more time scratching your head again. I
>> have done this more than once. I probably shouldn't admit that but I'm
>> sure I'm not the only one.
>>
>> Cheers,
>> Alan
>>
>
>

[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors

[Gordon Sim (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998362#comment-14998362
 ] 

Gordon Sim commented on PROTON-1044:


In the attached reproducer, if you call container.stop() before trying to 
delete it, there is no leak of file descriptors. Once created the reactor must 
be stopped in order to clean everything up.

Trying out the following variation on the attached reproducer, I also see no 
growth in the number of consumed file descriptors:

{noformat}
import os
import gc
from time import sleep

from proton.utils import BlockingConnection


print os.getpid()

for i in range(1000):
print 'pass #{n}'.format(n=i)
con = None
try:
con = BlockingConnection('localhost')
except Exception as e:
print e
finally:
if con:
con.close()
del con
gc.collect()
sleep(1)
{noformat}

Note however that this is based on the latest code upstream, including the most 
recent fix to PROTON-1000 which may be relevant.

> Create/Delete of BlockingConnection leaks file descriptors
> --
>
> Key: PROTON-1044
> URL: https://issues.apache.org/jira/browse/PROTON-1044
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9
> Environment: Fedora 22
>Reporter: Jeff Ortel
> Attachments: jortel.py
>
>
> Each time a BlockingConnection is created, it creates a Container.  The 
> Container() opens (2) file descriptors which are never closed.  The result is 
> that (2) file descriptors are leaked for each time BlockingConnection() is 
> called even if properly closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-1005) Factor anonymous-relay handling out of the examples

[Gordon Sim (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim resolved PROTON-1005.

Resolution: Fixed

> Factor anonymous-relay handling out of the examples
> ---
>
> Key: PROTON-1005
> URL: https://issues.apache.org/jira/browse/PROTON-1005
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Reporter: Justin Ross
>Assignee: Gordon Sim
>
> We'd prefer to handle it internally so the user need not confront it.
> http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/proton_server.py.html
> http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/server.py.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors

[Gordon Sim (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998364#comment-14998364
 ] 

Gordon Sim commented on PROTON-1044:


Note the above snippet doesn't leak whether or not there is anything listening 
on the specified port.

> Create/Delete of BlockingConnection leaks file descriptors
> --
>
> Key: PROTON-1044
> URL: https://issues.apache.org/jira/browse/PROTON-1044
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9
> Environment: Fedora 22
>Reporter: Jeff Ortel
> Attachments: jortel.py
>
>
> Each time a BlockingConnection is created, it creates a Container.  The 
> Container() opens (2) file descriptors which are never closed.  The result is 
> that (2) file descriptors are leaked for each time BlockingConnection() is 
> called even if properly closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-1000) Connection leak on heartbeat-timeouted connections

[Gordon Sim (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim resolved PROTON-1000.

   Resolution: Fixed
Fix Version/s: (was: 0.11)
   0.12.0

> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor 
> with heartbeats set up, if some connection timeouts due to the heartbeats, 
> Proton does not close the TCP connection. That causes TCP connection leak, 
> despite gofer properly called BlockingConnection.close() and forgot any 
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does 
> not respond anyhow to the communication partner whatever it sends (in some 
> scenarios it sends some AMQP performative that Proton was assumed to respond, 
> in other scenario the communication peer dropped the TCP connection by 
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only 
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And 
> Proton ignores an attempt of Proton reactor to close the 
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File 
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in 
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s 
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection 
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File 
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in 
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File 
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in 
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s 
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection 
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my 
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK 
> packet for nonSSL connection, while it does not send anything for SSL 
> connection and continue for sending empty AMQP frames due to heartbeats 
> enabled forever)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PROTON-1042) Can't distinguish between null target and null address on a target

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998492#comment-14998492
 ] 

Robbie Gemmell edited comment on PROTON-1042 at 11/10/15 12:34 PM:
---

I would like to request this change for inclusion in 0.11.0.

Without the change Gordon made, it isn't possible for components using proton-c 
to distinguish between whether an arriving link attach frame had no target, or 
no address in its target. This distinction is crucial for supporting the 
anonymous relay node and ensuring the proper attach response is sent to clients 
(e.g see issued caused noted on QPID-6754 and DISPATCH-192).

I have tested the change by applying it to the first RC and using it with qpidd 
trunk, dispatch 0.5, and dispatch master.


was (Author: gemmellr):
I would like to request this change for inclusion in 0.11.0.

Without the change Gordon made, it isn't possible for components using proton-c 
to distinguish between whether an arriving link attach frame had no target, or 
no address in its target. This distinction is crucial for supporting the 
anonymous relay node and ensuring the proper attach response is sent to clients 
(e.g see issued caused noted on QPID-6754 and DISPATCH-192).

I have tested the change by applying it to the first RC and using it with qpidd 
tuink, dispatch 0.5, and dispatch master.

> Can't distinguish between null target and null address on a target
> --
>
> Key: PROTON-1042
> URL: https://issues.apache.org/jira/browse/PROTON-1042
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the 
> source for pn_do_attach() in transport.c, it appears that 'target' is used to 
> hold the target address and  if that is not specified (and the target is not 
> a coordinator, it is left as unspecified).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PROTON-1042) Can't distinguish between null target and null address on a target

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998492#comment-14998492
 ] 

Robbie Gemmell edited comment on PROTON-1042 at 11/10/15 12:34 PM:
---

I would like to request this change for inclusion in 0.11.0.

Without the change Gordon made, it isn't possible for components using proton-c 
to distinguish between whether an arriving link attach frame had no target, or 
no address in its target. This distinction is crucial for supporting the 
anonymous relay node and ensuring the proper attach response is sent to clients 
(e.g see issued caused noted on QPID-6754 and DISPATCH-192).

I have tested the change by applying it to the first RC and using it with qpidd 
tuink, dispatch 0.5, and dispatch master.


was (Author: gemmellr):
I would like to request this change for inclusion in 0.11.0.

Without the change Gordon made, it isn't possible for components using proton 
to distinguish between whether an arriving link attach frame had no target, or 
no address in its target. This distinction is crucial for supporting the 
anonymous relay node and ensuring the proper attach response is sent to clients 
(e.g see issued caused noted on QPID-6754 and DISPATCH-192).

I have tested the change by applying it to the first RC and using it with qpidd 
tuink, dispatch 0.5, and dispatch master.

> Can't distinguish between null target and null address on a target
> --
>
> Key: PROTON-1042
> URL: https://issues.apache.org/jira/browse/PROTON-1042
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the 
> source for pn_do_attach() in transport.c, it appears that 'target' is used to 
> hold the target address and  if that is not specified (and the target is not 
> a coordinator, it is left as unspecified).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton 0.11.0 release update - The release candidate

[Robbie Gemmell]

I would like to request
https://issues.apache.org/jira/browse/PROTON-1042 for inclusion in
0.11.0. More details on the JIRA.

Robbie

On 9 November 2015 at 18:26, Justin Ross  wrote:
> Okay, I don't object to a respin to pick this up.  If anyone else does,
> speak up.  Alan, please line up a reviewer to comment on PROTON-949.
>
> Take notice!  Last call: I'm going to spin for RC 2 tomorrow and start the
> vote shortly after.  If you are aware of any problems, speak now.
>
> Thanks,
> Justin
>
> On Mon, Nov 9, 2015 at 10:59 AM, aconway  wrote:
>
>> On Tue, 2015-11-03 at 22:15 -0500, Justin Ross wrote:
>> > Hi, all.  The RC is now available here:
>> >
>> >   https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-rc/
>> >
>> > Maven staging repo:
>> >
>> >   https://repository.apache.org/content/repositories/orgapacheqpid-10
>> > 48/
>> >
>> > I will be away from my keyboard for the remainder of this week.  On
>> > Monday,
>> > the 9th, I will start the release vote if no blockers have been
>> > discovered
>> > in the interim.
>> >
>> > Thank you very much to everyone who tested the alpha and beta.  If
>> > you've
>> > not yet taken a look, please test the RC and report your results.
>> >
>>
>>
>> https://issues.apache.org/jira/browse/PROTON-949 is not in the RC. It
>> is not a regression but it is a *very* perplexing build failure with a
>> very low risk fix, IMO we should get it in there.
>>
>> Not only is it very hard to figure out why it won't build, but when you
>> finally fix the problem by removing the ccache swig binary, it
>> magically comes back when swig happens to get auto-updated by
>> yum/dnf/whatever and you waste more time scratching your head again. I
>> have done this more than once. I probably shouldn't admit that but I'm
>> sure I'm not the only one.
>>
>> Cheers,
>> Alan
>>

[jira] [Commented] (PROTON-1042) Can't distinguish between null target and null address on a target

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998492#comment-14998492
 ] 

Robbie Gemmell commented on PROTON-1042:


I would like to request this change for inclusion in 0.11.0.

Without the change Gordon made, it isn't possible for components using proton 
to distinguish between whether an arriving link attach frame had no target, or 
no address in its target. This distinction is crucial for supporting the 
anonymous relay node and ensuring the proper attach response is sent to clients 
(e.g see issued caused noted on QPID-6754 and DISPATCH-192).

I have tested the change by applying it to the first RC and using it with qpidd 
tuink, dispatch 0.5, and dispatch master.

> Can't distinguish between null target and null address on a target
> --
>
> Key: PROTON-1042
> URL: https://issues.apache.org/jira/browse/PROTON-1042
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the 
> source for pn_do_attach() in transport.c, it appears that 'target' is used to 
> hold the target address and  if that is not specified (and the target is not 
> a coordinator, it is left as unspecified).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1042) Can't distinguish between null target and null address on a target

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998548#comment-14998548
 ] 

Justin Ross commented on PROTON-1042:
-

Reviewed and tested by Robbie.  Approved for 0.11.0.

> Can't distinguish between null target and null address on a target
> --
>
> Key: PROTON-1042
> URL: https://issues.apache.org/jira/browse/PROTON-1042
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the 
> source for pn_do_attach() in transport.c, it appears that 'target' is used to 
> hold the target address and  if that is not specified (and the target is not 
> a coordinator, it is left as unspecified).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1042) Can't distinguish between null target and null address on a target

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998593#comment-14998593
 ] 

ASF subversion and git services commented on PROTON-1042:
-

Commit 88f5129f7fdbeb2cddaa35e8c72cdabc96573040 in qpid-proton's branch 
refs/heads/0.11.x from [~gsim]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=88f5129 ]

PROTON-1042: Ensure terminus type is correct for a target even if the address 
is null

(cherry picked from commit 1b1b2e596a974ec4fedf1ca3d985f0d62a730b61)


> Can't distinguish between null target and null address on a target
> --
>
> Key: PROTON-1042
> URL: https://issues.apache.org/jira/browse/PROTON-1042
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the 
> source for pn_do_attach() in transport.c, it appears that 'target' is used to 
> hold the target address and  if that is not specified (and the target is not 
> a coordinator, it is left as unspecified).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1042) Can't distinguish between null target and null address on a target

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1042:
---
Affects Version/s: (was: 0.11)
   0.10
Fix Version/s: (was: 0.12.0)
   0.11

I have cherry-picked the fix on to the 0.11.x branch for inclusion in the next 
0.11.0 RC, updating JIRA versions accordingly.

> Can't distinguish between null target and null address on a target
> --
>
> Key: PROTON-1042
> URL: https://issues.apache.org/jira/browse/PROTON-1042
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the 
> source for pn_do_attach() in transport.c, it appears that 'target' is used to 
> hold the target address and  if that is not specified (and the target is not 
> a coordinator, it is left as unspecified).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)