[jira] [Commented] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222029#comment-16222029
]
Keith Wall commented on QPID-7981:
--
Changes look reasonable to me.
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame)
[jira] [Updated] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7981:
-
Priority: Minor (was: Major)
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> SEND[/10.211.55.13:52
[jira] [Resolved] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-7981.
--
Resolution: Fixed
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> SEND[/10.211.55.13:52035|0] :
[jira] [Commented] (QPID-7646) [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support values > 1
[ https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222055#comment-16222055 ] ASF subversion and git services commented on QPID-7646: --- Commit 67f78d364864f2df520e18592dd8eb7f639a7e8d in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=67f78d3 ] QPID-7646: [Broker-J] Fix racy tests > [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support > values > 1 > --- > > Key: QPID-7646 > URL: https://issues.apache.org/jira/browse/QPID-7646 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > Attachments: QPID-7646-transaction-stats-refactoring.tar.gz > > > During the review of QPID-7633 it was noted: > bq. Why do we only return 0 or 1 from > AbstractAMQPSession#getLocalTransactionOpen. That seems wrong. > which was followed up by Rob: > bq. On getLocalTransactionOpen, I agree that looks very dodgy. In AMQP 0-x > the value will only be 0 or 1, but I'm not sure the implementation the we > have now is safe. I think the implementations will need to define this > properly (i.e. the calculation will need to be atomic, and the value may be > > 1 for AMQP 1.0 ) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 (as daemon - we are not interested in its output at this point, available at broker1/qpidd.log if required) with "qpidd --config broker1/qpidd.conf -d" * Start the broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are at
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Attachment: segfault-repoduce.tar.gz > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Unpack the attached tarball to an empty directory (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so t
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Unpack the attached tarball to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a b
[jira] [Commented] (QPID-7962) [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back when Flow with drain flag set is received from client
[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222355#comment-16222355
]
ASF subversion and git services commented on QPID-7962:
---
Commit 0c6bc977321a94d1c1e91d00c74f53200d40 in qpid-broker-j's branch
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0c6bc97 ]
QPID-7962: [Broker-J, AMQP 1.0] In some circumstances Broker fails to send Flow
back when Flow with drain flag set is received from client.
* When message is stolen from consumer add it to the queue's list of
interested consumers
* Rename QueueConsumer# and ConsumerTarget#queueEmpty to #noMessagesAvailable.
This is now always called when we currently cannot deliver messages to this
consumer.
This can occur when
* there is no message (the queue is empty)
* existing messages do not pass through the consumer's filters
* the consumer has no credit
* there is a different consumer with higher priority and credit blocking
delivery to this lower priority consumer
The effect of this method is potential auto-close on 0-8 and potential
credit draining on 1.0.
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> --
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch,
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222360#comment-16222360
]
ASF subversion and git services commented on QPID-7399:
---
Commit 2422183b6a9d9bedf1aebd218e693bb3e82eeca1 in qpid-broker-j's branch
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2422183 ]
QPID-7399: [Broker-J] Catch ClosedSelectorException which can occur during
shutdown
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222358#comment-16222358
]
Lorenz Quack commented on QPID-7399:
My analysis (current revision is 62a) is as follows:
# The selector thread detects acceptable keys and puts the Runnable on line 196
onto the {{_workQueue}}.
# In the meantime something closes the AmqpPort which calls
{{AmqpPortImpl#onClose}} -> {{TCPandSSLTransport#close}} ->
{{NetworkConnectionScheduler#close}} -> {{SelectorThread#close}} which sets
{{_closed}} to {{true}}.
# The selector thread now reaches the end of the while loop in
{{SelectionTask#performSelect}} and calls {{SelectionTask#closeSelector}} which
closes the {{_selector}}.
# Now a different IO-Thread picks up the Runnable from step 1. from the
{{_workQueue}} and starts executing it. Notice that the Runnable is a closure
around the former selector thread's {{SelectorTask}} (the one who's
{{_selector}} was closed in step 3.).
# When trying to use the {{_selector}} in line 210 we get the above
{{ClosedSelectorException}}
For now I will simply catch the exception which seems to occur rarely.
Since {{Selector#close}} is synchronized on the selector itself (see
Concurrency section of [the
docs|https://docs.oracle.com/javase/8/docs/api/java/nio/channels/Selector.html])
we could alternatively synchronize a block around the call to
{{channel.register}} in line 210.
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-98) Change Proton C++ Receiver shims to use latest non-deprecated API calls
[
https://issues.apache.org/jira/browse/QPIDIT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222368#comment-16222368
]
ASF subversion and git services commented on QPIDIT-98:
---
Commit 3881d008df839c99e6b28b4f5030f8731d2291eb in qpid-interop-test's branch
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=3881d00 ]
QPIDIT-98: Changed proton::default_container to proton::container (as the
former is now deprecated)
> Change Proton C++ Receiver shims to use latest non-deprecated API calls
> ---
>
> Key: QPIDIT-98
> URL: https://issues.apache.org/jira/browse/QPIDIT-98
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Improvement
> Components: Proton C++ Shim
>Affects Versions: 0.1.0-SNAPSHOT
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> After recent updates to the Proton C++, calls to {{proton::value::get<>()}}
> are deprecated with warnings. Change the code to use the recommended
> {{proton::get<>()}} calls instead.
> There is also a possibility that the use of {{proton::default_container}} is
> also deprecated, but it is currently not producing a warning.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7962) [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back when Flow with drain flag set is received from client
[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222365#comment-16222365
]
Lorenz Quack commented on QPID-7962:
The commit message is incorrect. I removed the first point mentioned from the
commit. It no longer explicitly adds a consumer to the interested list if a
message is stolen.
Keith and I came to the conclusion, that it would not be necessary since the
message, once acquired, is delivered to the consumer regardless so the normal
process of adding itself to the interested list after delivery should kick in.
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> --
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch,
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-97) Release qpid-interop-test 0.1.0
[ https://issues.apache.org/jira/browse/QPIDIT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222367#comment-16222367 ] ASF subversion and git services commented on QPIDIT-97: --- Commit 790059a3849b61cf4bc9e0a10078c9a4a4f218a8 in qpid-interop-test's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=790059a ] QPIDIT-97: Workaround in cmake script for RHEL7 Java_FOUND issue, also added min version of Proton to 0.18 > Release qpid-interop-test 0.1.0 > --- > > Key: QPIDIT-97 > URL: https://issues.apache.org/jira/browse/QPIDIT-97 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Release qpid-interop-test version 0.1.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7962) [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back when Flow with drain flag set is received from client
[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7962.
Resolution: Fixed
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> --
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch,
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7399:
--
Assignee: Keith Wall (was: Lorenz Quack)
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7399:
--
Assignee: Lorenz Quack
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7399:
---
Status: Reviewable (was: In Progress)
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Affects Version/s: qpid-cpp-1.36.0 > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Attachment: segfault-fix.patch > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Comment: was deleted (was: I'm incongruously logging this without the promised attachments in order to save the report in its current form. I also need to verify whether or not the bug applies to 1.36 or just master. ) > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start the broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached [^segfault-fix.patch]) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached patch) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Richardson updated QPID-7991: --- Description: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached [^segfault-fix.patch]) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. was: Segfault occurs on a brackground thread within about 5-10 seconds of broker startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, frames #3 and #5 are of particular relevance. The unchecked Bridge::shared_ptr derived from the iterator is null and the invocation of bridge->closed() triggers the segfault. Adding a simple null check (as per attached [^segfault-fix.patch]) fixes the segfault but not the underlying reason for the null pointer. The segfault appears to be related to how a second broker (henceforth "broker1") is configured; this is the one to which the links are established. Without broker1, the "segfaulting broker" (aka "broker2") does not do its thing. It may be that broker1 returns invalid data to broker2 but this is not in the scope of this bug report, which focuses on the segfault. h2. Reproduce Unfortunately the steps to arrive at this situation are not clear so the reproduce is a bit hacky - the data directory, config file and some certs for the two brokers are attached as a tarball in the hope that they can be arranged in such a way as to provide a reproduce in lieu of a purely step-based procedure. Steps to reproduce: * Temporarily add a DNS alias to the local machine of "octopussy" (necessary due to cert config and durable link config in broker2's data store) * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory (assumed to be cwd) * Start the broker1 with "qpidd --config broker1/qpidd.conf" * In another shell with the same cwd, start broker2 with "qpidd --config broker2/qpidd.conf" * Observe segfault in broker2 after 5-10 seconds. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2
[jira] [Commented] (QPID-7713) Clang build fails with link error
[
https://issues.apache.org/jira/browse/QPID-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222435#comment-16222435
]
ASF subversion and git services commented on QPID-7713:
---
Commit 3b789332cc5ca02a7bddee04751b8f229d4603a5 in qpid-cpp's branch
refs/heads/master from [~jr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=3b78933 ]
QPID-7713: The proximate fix for the clang linking problem
> Clang build fails with link error
> -
>
> Key: QPID-7713
> URL: https://issues.apache.org/jira/browse/QPID-7713
> Project: Qpid
> Issue Type: Bug
> Components: C++ Build
> Environment: Fedora 25 x86-64, Clang 3.9.1
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> {noformat}
> CXX=clang++ cmake .. && make -j8
> ---
> [100%] Linking CXX executable event_driven_list_agents
> [100%] Built target qmf2_event_driven_list_agents
> [100%] Linking CXX executable agent
> [100%] Built target qmf2_agent
> [100%] Linking CXX shared module cqmf2_ruby.so
> [100%] Built target cqmf2_ruby
> 1 warning generated.
> [100%] Linking CXX shared module _cqmf2.so
> [100%] Built target _cqmf2
> [100%] Linking CXX executable unit_test
> /usr/bin/ld: CMakeFiles/unit_test.dir/ExchangeTest.cpp.o: undefined reference
> to symbol 'pthread_rwlock_init@@GLIBC_2.2.5'
> /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command
> line
> clang-3.9: error: linker command failed with exit code 1 (use -v to see
> invocation)
> src/tests/CMakeFiles/unit_test.dir/build.make:1479: recipe for target
> 'src/tests/unit_test' failed
> make[2]: *** [src/tests/unit_test] Error 1
> CMakeFiles/Makefile2:2715: recipe for target
> 'src/tests/CMakeFiles/unit_test.dir/all' failed
> make[1]: *** [src/tests/CMakeFiles/unit_test.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> real 4m22.309s
> user 25m59.212s
> sys 1m3.917s
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-cpp pull request #10: Assorted C++ build fixes for review
Github user asfgit closed the pull request at: https://github.com/apache/qpid-cpp/pull/10 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7893) compilation failure on Fedora 26
[ https://issues.apache.org/jira/browse/QPID-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222434#comment-16222434 ] ASF subversion and git services commented on QPID-7893: --- Commit c5363a48acc43949e74ae8d85a20858d2313de11 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=c5363a4 ] QPID-7893: Dubious fixes for initialization warnings > compilation failure on Fedora 26 > > > Key: QPID-7893 > URL: https://issues.apache.org/jira/browse/QPID-7893 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Build, C++ Client >Affects Versions: qpid-cpp-1.37.0 > Environment: Fedora 26 > GCC reports version as "gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)" > commit 55d4171a8155d9f6a07a48507e33d43b8cb6d904 from qpid-cpp master >Reporter: Robbie Gemmell >Assignee: Justin Ross >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: compile-failure.txt > > > When trying to compile qpid-cpp master (commit > 55d4171a8155d9f6a07a48507e33d43b8cb6d904) on Fedora 26, I get some > 'maybe-uninitialized' related complication failures (see attachment). > Adding "-DCMAKE_CXX_FLAGS=-Wno-error=maybe-uninitialized" to the initial > cmake run seemed to get things going though obviously might not be correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7860) [cpp] Build produces deprecation warnings on recent Fedora
[
https://issues.apache.org/jira/browse/QPID-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross resolved QPID-7860.
---
Resolution: Fixed
> [cpp] Build produces deprecation warnings on recent Fedora
> --
>
> Key: QPID-7860
> URL: https://issues.apache.org/jira/browse/QPID-7860
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
> Environment: Fedora 25
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: swig-deprecation.patch
>
>
> {noformat}
> -- Found SWIG: /usr/bin/swig (found version "3.0.11")
> -- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.13")
> -- Found Perl: /usr/bin/perl (found version "5.24.1")
> -- Found PerlLibs: /usr/lib64/libperl.so (found version "5.24.1")
> -- Building Python bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qpid/python/CMakeLists.txt:35 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qmf2/python/CMakeLists.txt:35 (swig_add_module)
> -- Building Ruby bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qpid/ruby/CMakeLists.txt:48 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qmf2/ruby/CMakeLists.txt:39 (swig_add_module)
> -- Building Perl bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qpid/perl/CMakeLists.txt:31 (swig_add_module)
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/jross/code/qpid-cpp/bld
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7920) Qpid C++ 1.37.0 release tasks
[ https://issues.apache.org/jira/browse/QPID-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222438#comment-16222438 ] ASF subversion and git services commented on QPID-7920: --- Commit bacf5bee03665a7009ba824b65f5d9dc60547a78 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=bacf5be ] QPID-7920: Increment the max safe proton version > Qpid C++ 1.37.0 release tasks > - > > Key: QPID-7920 > URL: https://issues.apache.org/jira/browse/QPID-7920 > Project: Qpid > Issue Type: Task > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Robbie Gemmell > Fix For: qpid-cpp-1.37.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7860) [cpp] Build produces deprecation warnings on recent Fedora
[
https://issues.apache.org/jira/browse/QPID-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222436#comment-16222436
]
ASF subversion and git services commented on QPID-7860:
---
Commit 2349e0b79c9204b5ed37ec2a1b44625e1c46cc6d in qpid-cpp's branch
refs/heads/master from [~jr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=2349e0b ]
QPID-7860: Fix swig deprecation warnings
> [cpp] Build produces deprecation warnings on recent Fedora
> --
>
> Key: QPID-7860
> URL: https://issues.apache.org/jira/browse/QPID-7860
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
> Environment: Fedora 25
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: swig-deprecation.patch
>
>
> {noformat}
> -- Found SWIG: /usr/bin/swig (found version "3.0.11")
> -- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.13")
> -- Found Perl: /usr/bin/perl (found version "5.24.1")
> -- Found PerlLibs: /usr/lib64/libperl.so (found version "5.24.1")
> -- Building Python bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qpid/python/CMakeLists.txt:35 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qmf2/python/CMakeLists.txt:35 (swig_add_module)
> -- Building Ruby bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qpid/ruby/CMakeLists.txt:48 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qmf2/ruby/CMakeLists.txt:39 (swig_add_module)
> -- Building Perl bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226
> (message):
> SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
> bindings/qpid/perl/CMakeLists.txt:31 (swig_add_module)
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/jross/code/qpid-cpp/bld
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7893) compilation failure on Fedora 26
[ https://issues.apache.org/jira/browse/QPID-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222440#comment-16222440 ] ASF subversion and git services commented on QPID-7893: --- Commit 2787235079659126474e24c285823c69bb31119d in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=2787235 ] QPID-7893: Improvements to initialzation fixes from review > compilation failure on Fedora 26 > > > Key: QPID-7893 > URL: https://issues.apache.org/jira/browse/QPID-7893 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Build, C++ Client >Affects Versions: qpid-cpp-1.37.0 > Environment: Fedora 26 > GCC reports version as "gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)" > commit 55d4171a8155d9f6a07a48507e33d43b8cb6d904 from qpid-cpp master >Reporter: Robbie Gemmell >Assignee: Justin Ross >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: compile-failure.txt > > > When trying to compile qpid-cpp master (commit > 55d4171a8155d9f6a07a48507e33d43b8cb6d904) on Fedora 26, I get some > 'maybe-uninitialized' related complication failures (see attachment). > Adding "-DCMAKE_CXX_FLAGS=-Wno-error=maybe-uninitialized" to the initial > cmake run seemed to get things going though obviously might not be correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7936) Allow packagers to override Perl and Ruby binding install prefixes
[ https://issues.apache.org/jira/browse/QPID-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222439#comment-16222439 ] ASF subversion and git services commented on QPID-7936: --- Commit e2c8ff452b6a0456f0ce12d94e9ce7143d212c57 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=e2c8ff4 ] QPID-7936: Allow overriding Perl and Ruby install prefixes > Allow packagers to override Perl and Ruby binding install prefixes > -- > > Key: QPID-7936 > URL: https://issues.apache.org/jira/browse/QPID-7936 > Project: Qpid > Issue Type: Improvement > Components: Perl Client, Ruby Client >Affects Versions: qpid-cpp-1.36.0 >Reporter: Justin Ross >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.37.0 > > > Packagers need to install to OS-expected locations. This patch from Darryl > Pierce provides a way for them to override the install locations with cmake > variables. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7936) Allow packagers to override Perl and Ruby binding install prefixes
[ https://issues.apache.org/jira/browse/QPID-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7936. --- Resolution: Done > Allow packagers to override Perl and Ruby binding install prefixes > -- > > Key: QPID-7936 > URL: https://issues.apache.org/jira/browse/QPID-7936 > Project: Qpid > Issue Type: Improvement > Components: Perl Client, Ruby Client >Affects Versions: qpid-cpp-1.36.0 >Reporter: Justin Ross >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.37.0 > > > Packagers need to install to OS-expected locations. This patch from Darryl > Pierce provides a way for them to override the install locations with cmake > variables. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7713) Clang build fails with link error
[
https://issues.apache.org/jira/browse/QPID-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross resolved QPID-7713.
---
Resolution: Fixed
> Clang build fails with link error
> -
>
> Key: QPID-7713
> URL: https://issues.apache.org/jira/browse/QPID-7713
> Project: Qpid
> Issue Type: Bug
> Components: C++ Build
> Environment: Fedora 25 x86-64, Clang 3.9.1
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> {noformat}
> CXX=clang++ cmake .. && make -j8
> ---
> [100%] Linking CXX executable event_driven_list_agents
> [100%] Built target qmf2_event_driven_list_agents
> [100%] Linking CXX executable agent
> [100%] Built target qmf2_agent
> [100%] Linking CXX shared module cqmf2_ruby.so
> [100%] Built target cqmf2_ruby
> 1 warning generated.
> [100%] Linking CXX shared module _cqmf2.so
> [100%] Built target _cqmf2
> [100%] Linking CXX executable unit_test
> /usr/bin/ld: CMakeFiles/unit_test.dir/ExchangeTest.cpp.o: undefined reference
> to symbol 'pthread_rwlock_init@@GLIBC_2.2.5'
> /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command
> line
> clang-3.9: error: linker command failed with exit code 1 (use -v to see
> invocation)
> src/tests/CMakeFiles/unit_test.dir/build.make:1479: recipe for target
> 'src/tests/unit_test' failed
> make[2]: *** [src/tests/unit_test] Error 1
> CMakeFiles/Makefile2:2715: recipe for target
> 'src/tests/CMakeFiles/unit_test.dir/all' failed
> make[1]: *** [src/tests/CMakeFiles/unit_test.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> real 4m22.309s
> user 25m59.212s
> sys 1m3.917s
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7893) compilation failure on Fedora 26
[ https://issues.apache.org/jira/browse/QPID-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7893. --- Resolution: Fixed > compilation failure on Fedora 26 > > > Key: QPID-7893 > URL: https://issues.apache.org/jira/browse/QPID-7893 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Build, C++ Client >Affects Versions: qpid-cpp-1.37.0 > Environment: Fedora 26 > GCC reports version as "gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)" > commit 55d4171a8155d9f6a07a48507e33d43b8cb6d904 from qpid-cpp master >Reporter: Robbie Gemmell >Assignee: Justin Ross >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: compile-failure.txt > > > When trying to compile qpid-cpp master (commit > 55d4171a8155d9f6a07a48507e33d43b8cb6d904) on Fedora 26, I get some > 'maybe-uninitialized' related complication failures (see attachment). > Adding "-DCMAKE_CXX_FLAGS=-Wno-error=maybe-uninitialized" to the initial > cmake run seemed to get things going though obviously might not be correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Blomquist updated PROTON-1660:
---
Description:
https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
This line was recently changed in qpid-proton master. It causes any project
that depends on a recent version of json to break when pulling together
dependencies. The pessimistic style of version constraint means that
qpid-proton requires a json version of >= 0.0, but < 1.
For instance, our project has a dependency on json 2.x. And, we see this error
when bundling with qpid-proton:
{code:none}
Bundler could not find compatible versions for gem "json":
In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
depends on json (~> 2.0.1)
qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
{code}
was:
https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
This line was recently changed in qpid-proton master. It causes any project
that depends on a recent version of json to break when pulling together
dependencies. The pessimistic style of version constraint means that
qpid-proton requires a json version of >= 0.0, but < 1.
For instance, our project has a dependency on json 2.x. And, we see this error
when bundling with qpid-proton:
{code:text}
Bundler could not find compatible versions for gem "json":
In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
depends on json (~> 2.0.1)
qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
{code}
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Greg Blomquist
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
Greg Blomquist created PROTON-1660:
--
Summary: The gemspec dependency on "json ~> 0" breaks anyone
dependning on a recent version of json
Key: PROTON-1660
URL: https://issues.apache.org/jira/browse/PROTON-1660
Project: Qpid Proton
Issue Type: Bug
Reporter: Greg Blomquist
https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
This line was recently changed in qpid-proton master. It causes any project
that depends on a recent version of json to break when pulling together
dependencies. The pessimistic style of version constraint means that
qpid-proton requires a json version of >= 0.0, but < 1.
For instance, our project has a dependency on json 2.x. And, we see this error
when bundling with qpid-proton:
{code:text}
Bundler could not find compatible versions for gem "json":
In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
depends on json (~> 2.0.1)
qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1652) [Windows] C Example tests fail
[
https://issues.apache.org/jira/browse/PROTON-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-1652:
Fix Version/s: proton-c-0.18.1
> [Windows] C Example tests fail
> --
>
> Key: PROTON-1652
> URL: https://issues.apache.org/jira/browse/PROTON-1652
> Project: Qpid Proton
> Issue Type: Bug
> Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
> Environment: Windows appveyor CI build
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.1
>
>
> Having re enabled the C example tests, they prompty fail!
> {noformat}
> 23: ==
> 23: ERROR: test_send_abort_broker (__main__.CExampleTest)
> 23: Sending aborted messages to a broker
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 97, in
> test_send_abort_broker
> 23: b.proc.wait_re("Message aborted\n"*MESSAGES)
> 23: File "C:\projects\qpid-proton\tools\py\proctest.py", line 144, in
> wait_re
> 23: raise ProcError(self, "gave up waiting for '%s' after %ss" % (regexp,
> timeout))
> 23: ProcError: gave up waiting for 'Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: ' after 10s (exit=None) command:
> 23: broker 1467
> 23:
> 23: Failed to open the file holding the private key:
> ssl_certs/tserver-full.p12 : The system cannot find the path specified.
> 23: listening
> 23:
> 23:
> 23: ==
> 23: ERROR: test_send_abort_direct (__main__.CExampleTest)
> 23: Send aborted messages to the direct server
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 113, in
> test_send_abort_direct
> 23: d.wait_re(expect)
> 23: File "C:\projects\qpid-proton\tools\py\proctest.py", line 144, in
> wait_re
> 23: raise ProcError(self, "gave up waiting for '%s' after %ss" % (regexp,
> timeout))
> 23: ProcError: gave up waiting for 'listening
> 23: {"sequence"=1}
> 23: {"sequence"=2}
> 23: {"sequence"=3}
> 23: {"sequence"=4}
> 23: {"sequence"=5}
> 23: {"sequence"=6}
> 23: {"sequence"=7}
> 23: {"sequence"=8}
> 23: {"sequence"=9}
> 23: {"sequence"=10}
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: ' after 10s (exit=None) command:
> 23: direct 1470 examples 20
> 23:
> 23: listening
> 23: {"sequence"=1}
> 23: {"sequence"=2}
> 23: {"sequence"=3}
> 23: {"sequence"=4}
> 23: {"sequence"=5}
> 23: {"sequence"=6}
> 23: {"sequence"=7}
> 23: {"sequence"=8}
> 23: {"sequence"=9}
> 23: {"sequence"=10}
> 23:
> 23:
> 23: ==
> 23: FAIL: test_send_ssl_receive (__main__.CExampleTest)
> 23: Send first then receive
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 122, in
> test_send_ssl_receive
> 23: self.assertEqual(send_expect(), self.runex("send-ssl", b.port))
> 23: AssertionError: '10 messages sent and acknowledged\n' != ''
> 23:
> 23: --
> 23: Ran 7 tests in 20.372s
> 23:
> 23: FAILED (failures=1, errors=2)
> {noformat}
> There is more than one failure here and a glimpse that something may wrong
> with the SSL set up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1652) [Windows] C Example tests fail
[
https://issues.apache.org/jira/browse/PROTON-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher reassigned PROTON-1652:
---
Assignee: Andrew Stitcher
> [Windows] C Example tests fail
> --
>
> Key: PROTON-1652
> URL: https://issues.apache.org/jira/browse/PROTON-1652
> Project: Qpid Proton
> Issue Type: Bug
> Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
> Environment: Windows appveyor CI build
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.1
>
>
> Having re enabled the C example tests, they prompty fail!
> {noformat}
> 23: ==
> 23: ERROR: test_send_abort_broker (__main__.CExampleTest)
> 23: Sending aborted messages to a broker
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 97, in
> test_send_abort_broker
> 23: b.proc.wait_re("Message aborted\n"*MESSAGES)
> 23: File "C:\projects\qpid-proton\tools\py\proctest.py", line 144, in
> wait_re
> 23: raise ProcError(self, "gave up waiting for '%s' after %ss" % (regexp,
> timeout))
> 23: ProcError: gave up waiting for 'Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: ' after 10s (exit=None) command:
> 23: broker 1467
> 23:
> 23: Failed to open the file holding the private key:
> ssl_certs/tserver-full.p12 : The system cannot find the path specified.
> 23: listening
> 23:
> 23:
> 23: ==
> 23: ERROR: test_send_abort_direct (__main__.CExampleTest)
> 23: Send aborted messages to the direct server
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 113, in
> test_send_abort_direct
> 23: d.wait_re(expect)
> 23: File "C:\projects\qpid-proton\tools\py\proctest.py", line 144, in
> wait_re
> 23: raise ProcError(self, "gave up waiting for '%s' after %ss" % (regexp,
> timeout))
> 23: ProcError: gave up waiting for 'listening
> 23: {"sequence"=1}
> 23: {"sequence"=2}
> 23: {"sequence"=3}
> 23: {"sequence"=4}
> 23: {"sequence"=5}
> 23: {"sequence"=6}
> 23: {"sequence"=7}
> 23: {"sequence"=8}
> 23: {"sequence"=9}
> 23: {"sequence"=10}
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: ' after 10s (exit=None) command:
> 23: direct 1470 examples 20
> 23:
> 23: listening
> 23: {"sequence"=1}
> 23: {"sequence"=2}
> 23: {"sequence"=3}
> 23: {"sequence"=4}
> 23: {"sequence"=5}
> 23: {"sequence"=6}
> 23: {"sequence"=7}
> 23: {"sequence"=8}
> 23: {"sequence"=9}
> 23: {"sequence"=10}
> 23:
> 23:
> 23: ==
> 23: FAIL: test_send_ssl_receive (__main__.CExampleTest)
> 23: Send first then receive
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 122, in
> test_send_ssl_receive
> 23: self.assertEqual(send_expect(), self.runex("send-ssl", b.port))
> 23: AssertionError: '10 messages sent and acknowledged\n' != ''
> 23:
> 23: --
> 23: Ran 7 tests in 20.372s
> 23:
> 23: FAILED (failures=1, errors=2)
> {noformat}
> There is more than one failure here and a glimpse that something may wrong
> with the SSL set up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222555#comment-16222555
]
Jason Frey commented on PROTON-1660:
Fix would be to change it to ">= 0" or even better just remove the version
constraint entirely (which is equivalent to ">= 0", but is more idiomatic)
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Greg Blomquist
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-99) Install: npm warnings when installing rhea shim to system directory
Kim van der Riet created QPIDIT-99:
--
Summary: Install: npm warnings when installing rhea shim to system
directory
Key: QPIDIT-99
URL: https://issues.apache.org/jira/browse/QPIDIT-99
Project: Apache QPID Interoperability Test Suite
Issue Type: Bug
Components: Rhea JavaScript Shim
Reporter: Kim van der Riet
Assignee: Kim van der Riet
Priority: Minor
When installing using cmake to a system directory, at the end of the install
process there is the following npm warning:
{noformat}
npm WARN enoent ENOENT: no such file or directory, open
'/usr/local/libexec/qpid_interop_test/shims/rhea-js/package.json
{noformat}
This does not appear to affect functionality, and the rhea-js shims run
successfully against the other shims.
The error does not appear when installing to a local directory, ie with
CMAKE_INSTALL_PREFIX set to a local directory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-99) Install: npm warnings when installing rhea shim to system directory
[
https://issues.apache.org/jira/browse/QPIDIT-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated QPIDIT-99:
---
Affects Version/s: 0.1.0
> Install: npm warnings when installing rhea shim to system directory
> ---
>
> Key: QPIDIT-99
> URL: https://issues.apache.org/jira/browse/QPIDIT-99
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Rhea JavaScript Shim
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
>
> When installing using cmake to a system directory, at the end of the install
> process there is the following npm warning:
> {noformat}
> npm WARN enoent ENOENT: no such file or directory, open
> '/usr/local/libexec/qpid_interop_test/shims/rhea-js/package.json
> {noformat}
> This does not appear to affect functionality, and the rhea-js shims run
> successfully against the other shims.
> The error does not appear when installing to a local directory, ie with
> CMAKE_INSTALL_PREFIX set to a local directory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-97) Release qpid-interop-test 0.1.0
[ https://issues.apache.org/jira/browse/QPIDIT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-97: --- Affects Version/s: 0.1.0 > Release qpid-interop-test 0.1.0 > --- > > Key: QPIDIT-97 > URL: https://issues.apache.org/jira/browse/QPIDIT-97 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Release qpid-interop-test version 0.1.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7992) [Broker-J] Add auxiliary operation to dump links from link registry
Alex Rudyy created QPID-7992: Summary: [Broker-J] Add auxiliary operation to dump links from link registry Key: QPID-7992 URL: https://issues.apache.org/jira/browse/QPID-7992 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Alex Rudyy Fix For: qpid-java-broker-7.0.0 Qpid Broker-J does not expose any management functionality to manage links in the link registry. At least for testing purposes, the Broker should provide functionality to dump information about current links in the link registry. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7992) [Broker-J] Add auxiliary operation to dump links from link registry
[ https://issues.apache.org/jira/browse/QPID-7992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7992: - Attachment: 0001-QPID-7992-Broker-J-Add-auxiliary-operation-to-dump-l.patch > [Broker-J] Add auxiliary operation to dump links from link registry > --- > > Key: QPID-7992 > URL: https://issues.apache.org/jira/browse/QPID-7992 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7992-Broker-J-Add-auxiliary-operation-to-dump-l.patch > > > Qpid Broker-J does not expose any management functionality to manage links in > the link registry. At least for testing purposes, the Broker should provide > functionality to dump information about current links in the link registry. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1603) Windows C++ container does not compile multithreaded
[ https://issues.apache.org/jira/browse/PROTON-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1603. --- Resolution: Duplicate > Windows C++ container does not compile multithreaded > > > Key: PROTON-1603 > URL: https://issues.apache.org/jira/browse/PROTON-1603 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Cliff Jansen >Assignee: Andrew Stitcher > Fix For: proton-c-0.18.1 > > > For both VS2013 and VS2017 cmake proclaims: > HAS_STD_THREAD - Success > HAS_STD_MUTEX - Success > HAS_STD_ATOMIC - Success > yet proactor_container_impl.cpp does not compile > PN_CPP_SUPPORTS_THREADS sections. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1603) Windows C++ container does not compile multithreaded
[ https://issues.apache.org/jira/browse/PROTON-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reopened PROTON-1603: - > Windows C++ container does not compile multithreaded > > > Key: PROTON-1603 > URL: https://issues.apache.org/jira/browse/PROTON-1603 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Cliff Jansen >Assignee: Andrew Stitcher > Fix For: proton-c-0.18.1 > > > For both VS2013 and VS2017 cmake proclaims: > HAS_STD_THREAD - Success > HAS_STD_MUTEX - Success > HAS_STD_ATOMIC - Success > yet proactor_container_impl.cpp does not compile > PN_CPP_SUPPORTS_THREADS sections. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7993) [Broker-J] Links for shared durable subscribers are accumulated in the link registry
Alex Rudyy created QPID-7993:
Summary: [Broker-J] Links for shared durable subscribers are
accumulated in the link registry
Key: QPID-7993
URL: https://issues.apache.org/jira/browse/QPID-7993
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Reporter: Alex Rudyy
Only link with name equals to subscription name is deleted from the link
registry on unsubscribe of shared durable subscription. The other shared
durable subscription links with names containing index are left in link
registry forever. As result, such links can accumulate with time and cause OOM.
The steps to reproduce
* Apply patch from QPID-799
* Start the Broker
* Create shared durable subscriptions with 2 subscribers
* Close subscribers and unsubscribe the subscription
* Dump the link registry state using management operation
{{QueueManagingVirtualHost#dumpLinkRegistry}} . The link for the second shared
subscriber will be present in the dumped data
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7993) [Broker-J] Links for shared durable subscribers are accumulated in the link registry
[
https://issues.apache.org/jira/browse/QPID-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7993:
-
Description:
Only link with name equals to subscription name is deleted from the link
registry on unsubscribe of shared durable subscription. The other shared
durable subscription links with names containing index are left in link
registry forever. As result, such links can accumulate with time and cause OOM.
The steps to reproduce
* Apply patch from QPID-7992
* Start the Broker
* Create shared durable subscriptions with 2 subscribers
* Close subscribers and unsubscribe the subscription
* Dump the link registry state using management operation
{{QueueManagingVirtualHost#dumpLinkRegistry}} . The link for the second shared
subscriber will be present in the dumped data
was:
Only link with name equals to subscription name is deleted from the link
registry on unsubscribe of shared durable subscription. The other shared
durable subscription links with names containing index are left in link
registry forever. As result, such links can accumulate with time and cause OOM.
The steps to reproduce
* Apply patch from QPID-799
* Start the Broker
* Create shared durable subscriptions with 2 subscribers
* Close subscribers and unsubscribe the subscription
* Dump the link registry state using management operation
{{QueueManagingVirtualHost#dumpLinkRegistry}} . The link for the second shared
subscriber will be present in the dumped data
> [Broker-J] Links for shared durable subscribers are accumulated in the link
> registry
>
>
> Key: QPID-7993
> URL: https://issues.apache.org/jira/browse/QPID-7993
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Only link with name equals to subscription name is deleted from the link
> registry on unsubscribe of shared durable subscription. The other shared
> durable subscription links with names containing index are left in link
> registry forever. As result, such links can accumulate with time and cause
> OOM.
> The steps to reproduce
> * Apply patch from QPID-7992
> * Start the Broker
> * Create shared durable subscriptions with 2 subscribers
> * Close subscribers and unsubscribe the subscription
> * Dump the link registry state using management operation
> {{QueueManagingVirtualHost#dumpLinkRegistry}} . The link for the second
> shared subscriber will be present in the dumped data
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1660:
Fix Version/s: proton-c-0.18.1
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Greg Blomquist
> Fix For: proton-c-0.18.1
>
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned PROTON-1660:
---
Assignee: Alan Conway
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Reporter: Greg Blomquist
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1660:
Component/s: ruby-binding
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Reporter: Greg Blomquist
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222675#comment-16222675
]
Jason Frey commented on PROTON-1660:
FYI, on my system where I have json_pure also installed, I am seeing the
following error:
```
Fetching: json-0.4.3.gem (100%)
json's executable "edit_json.rb" conflicts with json_pure
Overwrite the executable? [yN] n
ERROR: Error installing qpid_proton:
"edit_json.rb" from json conflicts with installed executable from
json_pure
```
But that's because it resolves to 0.4.3 instead of the latest 2.1.0
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Reporter: Greg Blomquist
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-7991: -- Fix Version/s: qpid-cpp-1.37.0 > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json
[
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222675#comment-16222675
]
Jason Frey edited comment on PROTON-1660 at 10/27/17 5:01 PM:
--
FYI, on my system where I have json_pure also installed, I am seeing the
following error:
{code:ruby}
Fetching: json-0.4.3.gem (100%)
json's executable "edit_json.rb" conflicts with json_pure
Overwrite the executable? [yN] n
ERROR: Error installing qpid_proton:
"edit_json.rb" from json conflicts with installed executable from
json_pure
{code}
But that's because it resolves to 0.4.3 instead of the latest 2.1.0
was (Author: fryguy):
FYI, on my system where I have json_pure also installed, I am seeing the
following error:
```
Fetching: json-0.4.3.gem (100%)
json's executable "edit_json.rb" conflicts with json_pure
Overwrite the executable? [yN] n
ERROR: Error installing qpid_proton:
"edit_json.rb" from json conflicts with installed executable from
json_pure
```
But that's because it resolves to 0.4.3 instead of the latest 2.1.0
> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Reporter: Greg Blomquist
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>
> This line was recently changed in qpid-proton master. It causes any project
> that depends on a recent version of json to break when pulling together
> dependencies. The pessimistic style of version constraint means that
> qpid-proton requires a json version of >= 0.0, but < 1.
> For instance, our project has a dependency on json 2.x. And, we see this
> error when bundling with qpid-proton:
> {code:none}
> Bundler could not find compatible versions for gem "json":
> In Gemfile: manageiq-providers-azure was resolved to 0.1.0,
> which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which
> depends on json (~> 2.0.1)
> qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-97) Release qpid-interop-test 0.1.0
[ https://issues.apache.org/jira/browse/QPIDIT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222686#comment-16222686 ] ASF subversion and git services commented on QPIDIT-97: --- Commit 225e85788a876b58d6acf641c613da5d6225c5f3 in qpid-interop-test's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=225e857 ] QPIDIT-97: Reduced required Proton version from 0.18 to 0.17 because RHEL-7 does not have the 0.18 packages yet. > Release qpid-interop-test 0.1.0 > --- > > Key: QPIDIT-97 > URL: https://issues.apache.org/jira/browse/QPIDIT-97 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Release qpid-interop-test version 0.1.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1661) Incomplete name comparision in transport.c pn_find_link()
Nathan Campbell created PROTON-1661: --- Summary: Incomplete name comparision in transport.c pn_find_link() Key: PROTON-1661 URL: https://issues.apache.org/jira/browse/PROTON-1661 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.17.0, 0.11.1 Environment: RedHat EL 5 & 7 Reporter: Nathan Campbell Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0 Problem: Function "pn_find_link()" incorrectly returns a link when argument "name" matches first N characters of existing link. i.e.: 1) QPID client creates receiver with address "amq.topic/fooBar": Broker will call function pn_find_link( ssn, name = "fooBar", true) which returns NULL as expected. Link is initialized and receiver works as expected. 2) Some time later QPID client creates second receiver with address "amq.topic/foo": Broker will call function pn_find_link( ssn, name="foo", true) which incorrectly returns pointer to existing link. Expected behavior is to return NULL so that link will (later) be initialized. This is because if() starting on line 1268 of proton-c/src/core/transport.c only uses strncmp(). eg: "strncmp( "foo", "fooBar", 3) == 0" That if() also needs to check +sizes of the names+ and only do "strncmp()" if: "(name.size == strlen(pn_string_get(link->name)))" Symptoms: Qpid client blocks indefinitely on second ConnectionContext::createReceiver() waiting for link to be established. Broker never does PN_LINK_INIT because it incorrectly believes link already exists, client is hung waiting for message back from broker. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #124: PROTON-1622 Add coverage analysis into build system
Github user jdanekrh commented on the issue: https://github.com/apache/qpid-proton/pull/124 Already merged in. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #124: PROTON-1622 Add coverage analysis into build ...
Github user jdanekrh closed the pull request at: https://github.com/apache/qpid-proton/pull/124 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1652) [Windows] C Example tests fail
[
https://issues.apache.org/jira/browse/PROTON-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-1652.
-
Resolution: Fixed
> [Windows] C Example tests fail
> --
>
> Key: PROTON-1652
> URL: https://issues.apache.org/jira/browse/PROTON-1652
> Project: Qpid Proton
> Issue Type: Bug
> Components: examples, proton-c
>Affects Versions: proton-c-0.18.0
> Environment: Windows appveyor CI build
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.1
>
>
> Having re enabled the C example tests, they prompty fail!
> {noformat}
> 23: ==
> 23: ERROR: test_send_abort_broker (__main__.CExampleTest)
> 23: Sending aborted messages to a broker
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 97, in
> test_send_abort_broker
> 23: b.proc.wait_re("Message aborted\n"*MESSAGES)
> 23: File "C:\projects\qpid-proton\tools\py\proctest.py", line 144, in
> wait_re
> 23: raise ProcError(self, "gave up waiting for '%s' after %ss" % (regexp,
> timeout))
> 23: ProcError: gave up waiting for 'Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: ' after 10s (exit=None) command:
> 23: broker 1467
> 23:
> 23: Failed to open the file holding the private key:
> ssl_certs/tserver-full.p12 : The system cannot find the path specified.
> 23: listening
> 23:
> 23:
> 23: ==
> 23: ERROR: test_send_abort_direct (__main__.CExampleTest)
> 23: Send aborted messages to the direct server
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 113, in
> test_send_abort_direct
> 23: d.wait_re(expect)
> 23: File "C:\projects\qpid-proton\tools\py\proctest.py", line 144, in
> wait_re
> 23: raise ProcError(self, "gave up waiting for '%s' after %ss" % (regexp,
> timeout))
> 23: ProcError: gave up waiting for 'listening
> 23: {"sequence"=1}
> 23: {"sequence"=2}
> 23: {"sequence"=3}
> 23: {"sequence"=4}
> 23: {"sequence"=5}
> 23: {"sequence"=6}
> 23: {"sequence"=7}
> 23: {"sequence"=8}
> 23: {"sequence"=9}
> 23: {"sequence"=10}
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: Message aborted
> 23: ' after 10s (exit=None) command:
> 23: direct 1470 examples 20
> 23:
> 23: listening
> 23: {"sequence"=1}
> 23: {"sequence"=2}
> 23: {"sequence"=3}
> 23: {"sequence"=4}
> 23: {"sequence"=5}
> 23: {"sequence"=6}
> 23: {"sequence"=7}
> 23: {"sequence"=8}
> 23: {"sequence"=9}
> 23: {"sequence"=10}
> 23:
> 23:
> 23: ==
> 23: FAIL: test_send_ssl_receive (__main__.CExampleTest)
> 23: Send first then receive
> 23: --
> 23: Traceback (most recent call last):
> 23: File "C:/projects/qpid-proton/examples/c/example_test.py", line 122, in
> test_send_ssl_receive
> 23: self.assertEqual(send_expect(), self.runex("send-ssl", b.port))
> 23: AssertionError: '10 messages sent and acknowledged\n' != ''
> 23:
> 23: --
> 23: Ran 7 tests in 20.372s
> 23:
> 23: FAILED (failures=1, errors=2)
> {noformat}
> There is more than one failure here and a glimpse that something may wrong
> with the SSL set up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1661) Incomplete name comparision in transport.c pn_find_link()
[ https://issues.apache.org/jira/browse/PROTON-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Campbell updated PROTON-1661: Description: Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0 Problem: Function "pn_find_link()" incorrectly returns a link when argument "name" matches first N characters of existing link. i.e.: 1) QPID client creates receiver with address "amq.topic/fooBar": Broker will call function pn_find_link( ssn, name = "fooBar", true) which returns NULL as expected. Link is initialized and receiver works as expected. 2) Some time later the same QPID client creates second receiver with address "amq.topic/foo": Broker will call function pn_find_link( ssn, name="foo", true) which incorrectly returns pointer to existing link. Expected behavior is to return NULL so that link will (later) be initialized. This is because if() starting on line 1268 of proton-c/src/core/transport.c only uses strncmp(). eg: "strncmp( "foo", "fooBar", 3) == 0" That if() also needs to check +sizes of the names+ and only do "strncmp()" if: "(name.size == strlen(pn_string_get(link->name)))" Symptoms: Qpid client blocks indefinitely on second ConnectionContext::createReceiver() waiting for link to be established. Broker never does PN_LINK_INIT because it incorrectly believes link already exists, client is hung waiting for message back from broker. was: Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0 Problem: Function "pn_find_link()" incorrectly returns a link when argument "name" matches first N characters of existing link. i.e.: 1) QPID client creates receiver with address "amq.topic/fooBar": Broker will call function pn_find_link( ssn, name = "fooBar", true) which returns NULL as expected. Link is initialized and receiver works as expected. 2) Some time later QPID client creates second receiver with address "amq.topic/foo": Broker will call function pn_find_link( ssn, name="foo", true) which incorrectly returns pointer to existing link. Expected behavior is to return NULL so that link will (later) be initialized. This is because if() starting on line 1268 of proton-c/src/core/transport.c only uses strncmp(). eg: "strncmp( "foo", "fooBar", 3) == 0" That if() also needs to check +sizes of the names+ and only do "strncmp()" if: "(name.size == strlen(pn_string_get(link->name)))" Symptoms: Qpid client blocks indefinitely on second ConnectionContext::createReceiver() waiting for link to be established. Broker never does PN_LINK_INIT because it incorrectly believes link already exists, client is hung waiting for message back from broker. > Incomplete name comparision in transport.c pn_find_link() > - > > Key: PROTON-1661 > URL: https://issues.apache.org/jira/browse/PROTON-1661 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11.1, proton-c-0.17.0 > Environment: RedHat EL 5 & 7 >Reporter: Nathan Campbell > > Tested in both proton-c version 0.11.1 and 0.17.0 with qpid broker 1.36.0 > Problem: > Function "pn_find_link()" incorrectly returns a link when argument "name" > matches first N characters of existing link. > i.e.: > 1) QPID client creates receiver with address "amq.topic/fooBar": >Broker will call function pn_find_link( ssn, name = "fooBar", true) which > returns NULL as expected. Link is initialized and receiver works as expected. > 2) Some time later the same QPID client creates second receiver with address > "amq.topic/foo": > Broker will call function pn_find_link( ssn, name="foo", true) which > incorrectly returns pointer to existing link. Expected behavior is to return > NULL so that link will (later) be initialized. > This is because if() starting on line 1268 of proton-c/src/core/transport.c > only uses strncmp(). > eg: "strncmp( "foo", "fooBar", 3) == 0" > That if() also needs to check +sizes of the names+ and only do "strncmp()" if: > "(name.size == strlen(pn_string_get(link->name)))" > Symptoms: > Qpid client blocks indefinitely on second ConnectionContext::createReceiver() > waiting for link to be established. Broker never does PN_LINK_INIT because > it incorrectly believes link already exists, client is hung waiting for > message back from broker. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1662) Proton-c fails to compile with no cyrus SASL but OpenSSL
Andrew Stitcher created PROTON-1662: --- Summary: Proton-c fails to compile with no cyrus SASL but OpenSSL Key: PROTON-1662 URL: https://issues.apache.org/jira/browse/PROTON-1662 Project: Qpid Proton Issue Type: Bug Components: build, proton-c Affects Versions: proton-c-0.18.0 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.18.1 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
