[jira] [Commented] (PROTON-1656) [OSX] c-proactor-tests test_ipv4_ipv6 fails
[
https://issues.apache.org/jira/browse/PROTON-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16233527#comment-16233527
]
Roddie Kieley commented on PROTON-1656:
---
[~aconway] good to know as I had tried adding in the so_reuseport to go along
with the so_reuseaddr setsockopt as well as adding the close socket so that
reuse wasn't a factor but haven't had much luck on tweaking the test to pass at
this point.
[~gemmellr] there's a travis CI build of the PROTON-522 branch
[here|https://travis-ci.org/RoddieKieley/qpid-proton] although for the last
little while I had inadvertently added a tab in the yaml instead of spaces so
it wasn't running. Just fixed that up and while it's not green quite yet, it's
a good start as to what's required.
> [OSX] c-proactor-tests test_ipv4_ipv6 fails
> ---
>
> Key: PROTON-1656
> URL: https://issues.apache.org/jira/browse/PROTON-1656
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: proton-c
> Environment: OSX 10.11.6, Xcode 7.3.1
>Reporter: Roddie Kieley
>Priority: Major
> Fix For: proton-c-0.19.0
>
>
> This fails almost 100% of the time, usually with the following:
> {code}
> 10: TEST: test_ipv4_ipv6()
> 10:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637:
> check failed: No condition, expected :refused [test_ipv4_ipv6()]
> 10:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:638:
> check failed: No condition, expected :refused [test_ipv4_ipv6()]
> 10: FAIL: test_ipv4_ipv6() (2 errors)
> {code}
> or
> {code}
> 10: TEST: test_ipv4_ipv6()
> 10:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637:
> check failed: 'refused' not in 'connection timed out - connecting to
> 127.0.0.1:49446' [test_ipv4_ipv6()]
> 10: FAIL: test_ipv4_ipv6() (1 errors)
> {code}
> It passed once during testing yesterday but not sure what that is indicative
> of yet. Tested on Fedora 25 and always passes. Note that Fedora 25 is on a
> separate box and I do note that the OSX box has two 'inactive' entries in
> ifconfig which may or may not interfere with binding to 0.0.0.0 or ::1:
> {code}
> earth:126 rkieley$ ifconfig
> lo0: flags=8049 mtu 16384
> options=3
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff00
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> nd6 options=1
> gif0: flags=8010 mtu 1280
> stf0: flags=0<> mtu 1280
> en0: flags=8863 mtu 1500
> options=27
> ether d4:9a:20:0d:67:fc
> inet6 fe80::d69a:20ff:fe0d:67fc%en0 prefixlen 64 scopeid 0x4
> inet 192.168.2.4 netmask 0xff00 broadcast 192.168.2.255
> nd6 options=1
> media: autoselect (1000baseT )
> status: active
> en1: flags=8823 mtu 1500
> ether f8:1e:df:f4:46:8c
> nd6 options=1
> media: autoselect ()
> status: inactive
> fw0: flags=8863 mtu 494
> lladdr d4:9a:20:ff:fe:0d:67:fc
> nd6 options=1
> media: autoselect
> status: inactive
> earth:126 rkieley$
> {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-1671) Warn on conversions from the proton::returned type
Justin Ross created PROTON-1671: --- Summary: Warn on conversions from the proton::returned type Key: PROTON-1671 URL: https://issues.apache.org/jira/browse/PROTON-1671 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Justin Ross Assignee: Justin Ross Fix For: proton-c-0.19.0 Using the converted return type can easily result in thread-unsafe 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-1670) Configurable TLS versions
[ https://issues.apache.org/jira/browse/PROTON-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1670: Fix Version/s: (was: proton-c-0.18.0) proton-c-0.19.0 > Configurable TLS versions > - > > Key: PROTON-1670 > URL: https://issues.apache.org/jira/browse/PROTON-1670 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: proton-c-0.17.0 >Reporter: Justin Ross >Assignee: Andrew Stitcher > Labels: api, tls > Fix For: proton-c-0.19.0 > > > This link has examples of what httpd and nignx offer: > https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ -- 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-1670) Configurable TLS versions
Justin Ross created PROTON-1670: --- Summary: Configurable TLS versions Key: PROTON-1670 URL: https://issues.apache.org/jira/browse/PROTON-1670 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: proton-c-0.17.0 Reporter: Justin Ross Assignee: Andrew Stitcher Fix For: proton-c-0.18.0 This link has examples of what httpd and nignx offer: https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ -- 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] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227319#comment-16227319
]
Chris Richardson edited comment on QPID-7991 at 10/31/17 6:53 PM:
--
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
{code}
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
{code}
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the isDetached predicate is successfully executed on the Bridge
instance that subsequently transpired to be null, so presumably it was not null
at that time...
was (Author: chris.richardson):
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the invocation of the isDetached predicate is successfully executed
on the Bridge instance that subsequently transpired to be null, so presumably
it was not null at that time...
> 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] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227319#comment-16227319
]
Chris Richardson commented on QPID-7991:
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the invocation of the isDetached predicate is successfully executed
on the Bridge instance that subsequently transpired to be null, so presumably
it was not null at that time...
> 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] [Commented] (DISPATCH-862) have the CI build log detal which commit is being used from the Proton repo
[ https://issues.apache.org/jira/browse/DISPATCH-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227259#comment-16227259 ] Ganesh Murthy commented on DISPATCH-862: The echo statement (echo $(echo "Current proton checkout:") $(git rev-parse HEAD)) only prints properly in the *script* section of travis. In other sections it literally prints "echo $(echo "Current proton checkout:") $(git rev-parse HEAD)" So, I had to put it in the script section. > have the CI build log detal which commit is being used from the Proton repo > --- > > Key: DISPATCH-862 > URL: https://issues.apache.org/jira/browse/DISPATCH-862 > Project: Qpid Dispatch > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Ganesh Murthy >Priority: Minor > > Not release-specific, just saving a thought I've had a couple times now. > The Travis CI build job for Dispatch uses git submodules to pull in the > proton repo and then builds it locally before building Dispatch. Other than > estimating it based on the build times, I didn't see a way to establish what > commit is actually used when this occurs. It might be nice if the build > printed the commit details after setting up the submodule so that they are > just available in the log without investigation work. -- 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] (QPIDJMS-336) Refine failover reconnect behavior
[ https://issues.apache.org/jira/browse/QPIDJMS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227249#comment-16227249 ] ASF subversion and git services commented on QPIDJMS-336: - Commit 5987a021ffe4528d22ad033c2ca817a8ff148d67 in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=5987a02 ] QPIDJMS-336: change level on new logging to debug > Refine failover reconnect behavior > -- > > Key: QPIDJMS-336 > URL: https://issues.apache.org/jira/browse/QPIDJMS-336 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.27.0 > > > The current failover behavior attempt to connect to one URI from the possible > list of failover URIs when attempting to reestablish the connect before it > applies the configured reconnect delay. Instead it should attempt the full > batch before performing delay and backoff handling. > Also the reconnect attempts are counted per URI instead of once for each > cycle though the batch of available URIs meaning that if the value is to low > it might not be able to try all of the configured URIs before reaching the > max attempts. Track the attempts for the complete batch instead to allow all > to be tried at least once before giving 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] (DISPATCH-862) have the CI build log detal which commit is being used from the Proton repo
[ https://issues.apache.org/jira/browse/DISPATCH-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227201#comment-16227201 ] Robbie Gemmell commented on DISPATCH-862: - Sorry Ganesh, didn't see the update mail earlier. The output looks good, my only note is that I was planning to put it earlier in the log, at the point proton is checked out and installed since thats when I'd first wonder what the commit being used is. > have the CI build log detal which commit is being used from the Proton repo > --- > > Key: DISPATCH-862 > URL: https://issues.apache.org/jira/browse/DISPATCH-862 > Project: Qpid Dispatch > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Ganesh Murthy >Priority: Minor > > Not release-specific, just saving a thought I've had a couple times now. > The Travis CI build job for Dispatch uses git submodules to pull in the > proton repo and then builds it locally before building Dispatch. Other than > estimating it based on the build times, I didn't see a way to establish what > commit is actually used when this occurs. It might be nice if the build > printed the commit details after setting up the submodule so that they are > just available in the log without investigation work. -- 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-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227191#comment-16227191 ] Chris Richardson commented on QPID-7991: Tested, unfortunately no stack trace triggered by the "assert" 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 > 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] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16227110#comment-16227110
]
Alan Conway commented on QPID-7991:
---
I don't have the correct version of linearstore to run the reproducer, while I
sort that out - it might be instructive to run the reproducer with this patch
and post the stack trace if there is one (hopefully!)
modified src/qpid/broker/Link.cpp
@@ -415,6 +415,7 @@ void Link::destroy ()
void Link::add(Bridge::shared_ptr bridge)
{
Mutex::ScopedLock mutex(lock);
+assert(bridge)
created.push_back (bridge);
if (connection)
connection->requestIOProcessing (
That may show us when the null pointer is getting into the Link's list.
> 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] [Commented] (PROTON-1616) Review and fix Coverity issues for Proton
[ https://issues.apache.org/jira/browse/PROTON-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226972#comment-16226972 ] Robbie Gemmell commented on PROTON-1616: [~aconway] This JIRA was for 0.18.0. Since then 0.18.1 has been cut too. Please make a new JIRA for 0.19.0 and add the details there and use it for any future commits. > Review and fix Coverity issues for Proton > - > > Key: PROTON-1616 > URL: https://issues.apache.org/jira/browse/PROTON-1616 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.18.0 > > > See coverity report at https://scan4.coverity.com/reports.htm#v14283/p10556 -- 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] (DISPATCH-862) have the CI build log detal which commit is being used from the Proton repo
[ https://issues.apache.org/jira/browse/DISPATCH-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226955#comment-16226955 ] Ganesh Murthy edited comment on DISPATCH-862 at 10/31/17 3:11 PM: -- [~gemmellr] can you please look at this sample output from my branch travis build - https://travis-ci.org/ganeshmurthy/qpid-dispatch/builds/295336910#L2086 It prints out the sha of the qpid-proton checkin using the following command from the qpid-proton folder which is inside the qpid-dispatch folder - echo $(echo "Current proton checkout:") $(git rev-parse HEAD) was (Author: ganeshmurthy): [~gemmellr] can you please look at this sample output from my branch travis build - https://travis-ci.org/ganeshmurthy/qpid-dispatch/builds/295336910#L2022 It prints out the sha of the qpid-proton checkin using the following command from the qpid-proton folder which is inside the qpid-dispatch folder - echo $(echo "Current proton checkout:") $(git rev-parse HEAD) > have the CI build log detal which commit is being used from the Proton repo > --- > > Key: DISPATCH-862 > URL: https://issues.apache.org/jira/browse/DISPATCH-862 > Project: Qpid Dispatch > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Ganesh Murthy >Priority: Minor > > Not release-specific, just saving a thought I've had a couple times now. > The Travis CI build job for Dispatch uses git submodules to pull in the > proton repo and then builds it locally before building Dispatch. Other than > estimating it based on the build times, I didn't see a way to establish what > commit is actually used when this occurs. It might be nice if the build > printed the commit details after setting up the submodule so that they are > just available in the log without investigation work. -- 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-1616) Review and fix Coverity issues for Proton
[ https://issues.apache.org/jira/browse/PROTON-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226956#comment-16226956 ] ASF subversion and git services commented on PROTON-1616: - Commit e7f20252d4a62da92067fd715c1b20ebbf7d044b in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e7f2025 ] PROTON-1616: [c++ examples] missing break statement found by Coverity > Review and fix Coverity issues for Proton > - > > Key: PROTON-1616 > URL: https://issues.apache.org/jira/browse/PROTON-1616 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.18.0 > > > See coverity report at https://scan4.coverity.com/reports.htm#v14283/p10556 -- 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] (DISPATCH-862) have the CI build log detal which commit is being used from the Proton repo
[ https://issues.apache.org/jira/browse/DISPATCH-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226955#comment-16226955 ] Ganesh Murthy commented on DISPATCH-862: [~gemmellr] can you please look at this sample output from my branch travis build - https://travis-ci.org/ganeshmurthy/qpid-dispatch/builds/295336910#L2022 It prints out the sha of the qpid-proton checkin using the following command from the qpid-proton folder which is inside the qpid-dispatch folder - echo $(echo "Current proton checkout:") $(git rev-parse HEAD) > have the CI build log detal which commit is being used from the Proton repo > --- > > Key: DISPATCH-862 > URL: https://issues.apache.org/jira/browse/DISPATCH-862 > Project: Qpid Dispatch > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Ganesh Murthy >Priority: Minor > > Not release-specific, just saving a thought I've had a couple times now. > The Travis CI build job for Dispatch uses git submodules to pull in the > proton repo and then builds it locally before building Dispatch. Other than > estimating it based on the build times, I didn't see a way to establish what > commit is actually used when this occurs. It might be nice if the build > printed the commit details after setting up the submodule so that they are > just available in the log without investigation work. -- 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-7996) [Broker-J] Make operations regarding link registry thread safe
Alex Rudyy created QPID-7996: Summary: [Broker-J] Make operations regarding link registry thread safe Key: QPID-7996 URL: https://issues.apache.org/jira/browse/QPID-7996 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-broker-7.0.0 Reporter: Alex Rudyy Fix For: qpid-java-broker-7.0.1 Operations like removal of shared subscription links and 'null source lookup' for global shared subscriptions are not thread safe. -- 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-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:comment-tabpanel=16226883#comment-16226883
]
ASF subversion and git services commented on QPID-7993:
---
Commit 73c494fbd845ca8f826d0848daae83250c7e4599 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=73c494f ]
QPID-7993: [Broker-J][AMQP 1.0] Remove shared durable subscription links from
link registry on unsubscribe
> [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] [Closed] (PROTON-1655) go-test TestAuthPlain fails when SASL_IMPL is none
[
https://issues.apache.org/jira/browse/PROTON-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roddie Kieley closed PROTON-1655.
-
> go-test TestAuthPlain fails when SASL_IMPL is none
> --
>
> Key: PROTON-1655
> URL: https://issues.apache.org/jira/browse/PROTON-1655
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Affects Versions: proton-c-0.18.0
> Environment: OSX 10.11.6, Xcode 7.3.1, golang 1.9.1
> Fedora 25, gcc 6.3.1, go1.7.5
>Reporter: Roddie Kieley
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> Initially found this issue when testing the OSX work from PROTON-522, however
> after testing it fails in the same way on Fedora 25 when SASL_IMPL is none.
> As discussed in [this
> comment|https://issues.apache.org/jira/browse/PROTON-522?focusedCommentId=16218540=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16218540]
> when cyrus is configured for the sasl implementation the test fails due to
> the noted sasl_client_init parameter passing.
> {code}
> 11: Test command: /opt/local/bin/python
> "/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/env.py"
> "--"
> "GOPATH=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/go"
> "C
> GO_CFLAGS=-I/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/include
> -I/Users/rkieley/LocalProjects/issues/PROTON-522/121/proton-c/include"
> "CGO_LDFLAGS=-L/Users/rkieley/LocalProjects/issues/PROTON-522/121/p
> roton-c"
> "PN_INTEROP_DIR=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/tests/interop"
> "/opt/local/bin/go" "test" "-ldflags" "-r
> /Users/rkieley/LocalProjects/issues/PROTON-522/121/proton-c" "-v" "-race"
> "qpid.apach
> e.org/..."
> .
> .
> .
> 11: === RUN TestAuthPlain
> 11: --- FAIL: TestAuthPlain (0.02s)
> 11: electron_test.go:39: (from auth_test.go:64) amqp:unauthorized-access:
> Authentication failed [mech=PLAIN]
> {code}
> With a sasl implementation of 'none' configured we see that it attempts to
> use mech='none' and also fails:
> {code}
> 11: Test command: /opt/local/bin/python
> "/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/env.py"
> "--"
> "GOPATH=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/go"
> "C
> GO_CFLAGS=-I/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/include
> -I/Users/rkieley/LocalProjects/issues/PROTON-522/124/proton-c/include"
> "CGO_LDFLAGS=-L/Users/rkieley/LocalProjects/issues/PROTON-522/124/p
> roton-c"
> "PN_INTEROP_DIR=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/tests/interop"
> "/opt/local/bin/go" "test" "-ldflags" "-r
> /Users/rkieley/LocalProjects/issues/PROTON-522/124/proton-c" "-v" "-race"
> "qpid.apach
> e.org/..."
> .
> .
> .
> 11: === RUN TestAuthPlain
> 11: --- FAIL: TestAuthPlain (0.00s)
> 11: electron_test.go:39: (from auth_test.go:64) amqp:unauthorized-access:
> Authentication failed [mech=none]
> {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-1655) go-test TestAuthPlain fails when SASL_IMPL is none
[
https://issues.apache.org/jira/browse/PROTON-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226851#comment-16226851
]
Roddie Kieley commented on PROTON-1655:
---
[~aconway] This now skips correctly for me on both OSX and Fedora 25 when
SASL_IMPL is none.
> go-test TestAuthPlain fails when SASL_IMPL is none
> --
>
> Key: PROTON-1655
> URL: https://issues.apache.org/jira/browse/PROTON-1655
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Affects Versions: proton-c-0.18.0
> Environment: OSX 10.11.6, Xcode 7.3.1, golang 1.9.1
> Fedora 25, gcc 6.3.1, go1.7.5
>Reporter: Roddie Kieley
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> Initially found this issue when testing the OSX work from PROTON-522, however
> after testing it fails in the same way on Fedora 25 when SASL_IMPL is none.
> As discussed in [this
> comment|https://issues.apache.org/jira/browse/PROTON-522?focusedCommentId=16218540=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16218540]
> when cyrus is configured for the sasl implementation the test fails due to
> the noted sasl_client_init parameter passing.
> {code}
> 11: Test command: /opt/local/bin/python
> "/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/env.py"
> "--"
> "GOPATH=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/go"
> "C
> GO_CFLAGS=-I/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/include
> -I/Users/rkieley/LocalProjects/issues/PROTON-522/121/proton-c/include"
> "CGO_LDFLAGS=-L/Users/rkieley/LocalProjects/issues/PROTON-522/121/p
> roton-c"
> "PN_INTEROP_DIR=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/tests/interop"
> "/opt/local/bin/go" "test" "-ldflags" "-r
> /Users/rkieley/LocalProjects/issues/PROTON-522/121/proton-c" "-v" "-race"
> "qpid.apach
> e.org/..."
> .
> .
> .
> 11: === RUN TestAuthPlain
> 11: --- FAIL: TestAuthPlain (0.02s)
> 11: electron_test.go:39: (from auth_test.go:64) amqp:unauthorized-access:
> Authentication failed [mech=PLAIN]
> {code}
> With a sasl implementation of 'none' configured we see that it attempts to
> use mech='none' and also fails:
> {code}
> 11: Test command: /opt/local/bin/python
> "/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/env.py"
> "--"
> "GOPATH=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/go"
> "C
> GO_CFLAGS=-I/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/include
> -I/Users/rkieley/LocalProjects/issues/PROTON-522/124/proton-c/include"
> "CGO_LDFLAGS=-L/Users/rkieley/LocalProjects/issues/PROTON-522/124/p
> roton-c"
> "PN_INTEROP_DIR=/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/tests/interop"
> "/opt/local/bin/go" "test" "-ldflags" "-r
> /Users/rkieley/LocalProjects/issues/PROTON-522/124/proton-c" "-v" "-race"
> "qpid.apach
> e.org/..."
> .
> .
> .
> 11: === RUN TestAuthPlain
> 11: --- FAIL: TestAuthPlain (0.00s)
> 11: electron_test.go:39: (from auth_test.go:64) amqp:unauthorized-access:
> Authentication failed [mech=none]
> {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] [Comment Edited] (PROTON-1658) [OSX] ruby-example-test test_tools.rb initialize times out and hangs
[
https://issues.apache.org/jira/browse/PROTON-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226842#comment-16226842
]
Roddie Kieley edited comment on PROTON-1658 at 10/31/17 2:11 PM:
-
[~aconway] good to know re: the port-allocation strategy. A quick test shows
that the updated master no longer times out and hangs on OSX however it also
doesn't run any ruby tests for me on Fedora 25 atm; not sure if that is
expected behaviour for the moment.
was (Author: rkieley):
[~aconway] good to know re: the port-allocation strategy. A quick test shows
that the updated master no longer times out and hangs on OSX however it also
doesn't run the ruby-example-test or ruby-test-container tests for me on Fedora
25 atm; not sure if that is expected behaviour for the moment.
> [OSX] ruby-example-test test_tools.rb initialize times out and hangs
>
>
> Key: PROTON-1658
> URL: https://issues.apache.org/jira/browse/PROTON-1658
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: ruby-binding
> Environment: OSX 10.11.6, Xcode 7.3.1, ruby 2.0.0p648
>Reporter: Roddie Kieley
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> {code}
> test 1
> Start 1: ruby-example-test
> 1: Test command: /usr/bin/ruby "example_test.rb" "-v"
> 1: Environment variables:
> 1:
> PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Developer/SDKs/android-sdk-mac_x86-1.6_r1:/Developer/SDKs/android-sdk-mac_x86-1.6_r1/tools:/Developer/SDKs/adt-bundle-mac-x86_64/sdk/tools:/Developer/SDKs/adt-bundle-mac-x86_64/sdk/platform-tools:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c/bindings/ruby:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c
> 1:
> RUBYLIB=:/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/lib:/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests:/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/spec:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c/bindings/ruby:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c
> 1: Test timeout computed to be: 1500
> 1:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:60:in
> `initialize': Operation timed out - connect(2) (Errno::ETIMEDOUT)
> 1: from
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:60:in
> `open'
> 1: from
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:60:in
> `wait_port'
> 1: from example_test.rb:73:in `block in '
> 1: from
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:45:in
> `initialize'
> 1: from example_test.rb:70:in `new'
> 1: from example_test.rb:70:in `'
> ^C
> earth:126 rkieley$ ruby -v
> ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
> {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-1658) [OSX] ruby-example-test test_tools.rb initialize times out and hangs
[
https://issues.apache.org/jira/browse/PROTON-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226842#comment-16226842
]
Roddie Kieley commented on PROTON-1658:
---
[~aconway] good to know re: the port-allocation strategy. A quick test shows
that the updated master no longer times out and hangs on OSX however it also
doesn't run the ruby-example-test or ruby-test-container tests for me on Fedora
25 atm; not sure if that is expected behaviour for the moment.
> [OSX] ruby-example-test test_tools.rb initialize times out and hangs
>
>
> Key: PROTON-1658
> URL: https://issues.apache.org/jira/browse/PROTON-1658
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: ruby-binding
> Environment: OSX 10.11.6, Xcode 7.3.1, ruby 2.0.0p648
>Reporter: Roddie Kieley
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> {code}
> test 1
> Start 1: ruby-example-test
> 1: Test command: /usr/bin/ruby "example_test.rb" "-v"
> 1: Environment variables:
> 1:
> PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Developer/SDKs/android-sdk-mac_x86-1.6_r1:/Developer/SDKs/android-sdk-mac_x86-1.6_r1/tools:/Developer/SDKs/adt-bundle-mac-x86_64/sdk/tools:/Developer/SDKs/adt-bundle-mac-x86_64/sdk/platform-tools:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c/bindings/ruby:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c
> 1:
> RUBYLIB=:/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/lib:/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests:/Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/spec:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c/bindings/ruby:/Users/rkieley/LocalProjects/issues/PROTON-522/126/proton-c
> 1: Test timeout computed to be: 1500
> 1:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:60:in
> `initialize': Operation timed out - connect(2) (Errno::ETIMEDOUT)
> 1: from
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:60:in
> `open'
> 1: from
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:60:in
> `wait_port'
> 1: from example_test.rb:73:in `block in '
> 1: from
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/bindings/ruby/tests/test_tools.rb:45:in
> `initialize'
> 1: from example_test.rb:70:in `new'
> 1: from example_test.rb:70:in `'
> ^C
> earth:126 rkieley$ ruby -v
> ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
> {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] (QPID-7994) [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' on attaching of unsubscribe links for global durable shared subscriptions
[
https://issues.apache.org/jira/browse/QPID-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226744#comment-16226744
]
ASF subversion and git services commented on QPID-7994:
---
Commit 1c45ab9337ccee3db40a381d0a850805c5ce16f3 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=1c45ab9 ]
QPID-7994: [Broker-J][AMQP 1.0] Make sure global shared durable subscriptions
takes a copy of the terminus
> [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found'
> on attaching of unsubscribe links for global durable shared subscriptions
> --
>
> Key: QPID-7994
> URL: https://issues.apache.org/jira/browse/QPID-7994
> Project: Qpid
> Issue Type: Bug
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> As per [QPIDJMS-220|https://issues.apache.org/jira/browse/QPIDJMS-220]
> {quote}
> During unsubscribe, if a ClientID is set on the connection, a link named with
> the subscription name would be used to perform a 'null source lookup' for the
> subscription, as it is already for the existing non-shared durable
> subscriptions (see earlier for behaviour outline). If a ClientID is not set,
> the "|global" suffix will be added as shown previously..
> {quote}
> The current broker behaviour is not compliment with QPIDJMS-220. The broker
> create a new link instead of looking for existing link having name
> {{|global}} as suggested by QPIDJMS-220. For the new link,
> the local source is null. As result, 'not=found' error is reported.
> The broker should try to find an existing link in the link registry using
> link name only rather than name and a container ID as it does now. If link
> with given name is found, it should be used to recover the source. The broker
> should perform the search by link name only if {{SHARED}} capability is
> requested either on connection or attach itself as suggested by QPIDJMS-220:
> {quote}
> Additionally, while using connections that dont have a ClientID set, i.e
> using global shared susbcriptions, the link will have "shared" and "global"
> desired capabilities added as hints to the server that this is an attempt to
> attach to a 'global' shared subscription of the appropriate name derived from
> the link, aiding the server should no link with this name be known by it for
> the particular client container-id currently in use.
> {quote}
--
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] (DISPATCH-862) have the CI build log detal which commit is being used from the Proton repo
[ https://issues.apache.org/jira/browse/DISPATCH-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-862: -- Assignee: Ganesh Murthy > have the CI build log detal which commit is being used from the Proton repo > --- > > Key: DISPATCH-862 > URL: https://issues.apache.org/jira/browse/DISPATCH-862 > Project: Qpid Dispatch > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Ganesh Murthy >Priority: Minor > > Not release-specific, just saving a thought I've had a couple times now. > The Travis CI build job for Dispatch uses git submodules to pull in the > proton repo and then builds it locally before building Dispatch. Other than > estimating it based on the build times, I didn't see a way to establish what > commit is actually used when this occurs. It might be nice if the build > printed the commit details after setting up the submodule so that they are > just available in the log without investigation work. -- 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-1668) 0.18.1 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226727#comment-16226727 ] ASF subversion and git services commented on PROTON-1668: - Commit 42f67b651ce127d84f2a319e1a0f496f6aaac10e in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=42f67b6 ] PROTON-1668: update versions for 0.18.1-rc1 > 0.18.1 release tasks > > > Key: PROTON-1668 > URL: https://issues.apache.org/jira/browse/PROTON-1668 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > 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
[jira] [Commented] (PROTON-1669) 0.19.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226729#comment-16226729 ] ASF subversion and git services commented on PROTON-1669: - Commit 98dd87b1746387d3642efc01d1b79df8ddf90ad5 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=98dd87b ] PROTON-1668, PROTON-1669: bump versions for 0.19.0-SNAPSHOT This reverts commit 42f67b651ce127d84f2a319e1a0f496f6aaac10e. > 0.19.0 release tasks > > > Key: PROTON-1669 > URL: https://issues.apache.org/jira/browse/PROTON-1669 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.19.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] (PROTON-1668) 0.18.1 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226728#comment-16226728 ] ASF subversion and git services commented on PROTON-1668: - Commit 98dd87b1746387d3642efc01d1b79df8ddf90ad5 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=98dd87b ] PROTON-1668, PROTON-1669: bump versions for 0.19.0-SNAPSHOT This reverts commit 42f67b651ce127d84f2a319e1a0f496f6aaac10e. > 0.18.1 release tasks > > > Key: PROTON-1668 > URL: https://issues.apache.org/jira/browse/PROTON-1668 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > 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
[jira] [Commented] (PROTON-1668) 0.18.1 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226726#comment-16226726 ] ASF subversion and git services commented on PROTON-1668: - Commit 2c07cc30064bacf4f315ea60f2973ba213379bbc in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2c07cc3 ] PROTON-1668: update release helper script, use version rather than tag name for archive filename > 0.18.1 release tasks > > > Key: PROTON-1668 > URL: https://issues.apache.org/jira/browse/PROTON-1668 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > 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
[jira] [Commented] (QPID-7994) [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' on attaching of unsubscribe links for global durable shared subscriptions
[
https://issues.apache.org/jira/browse/QPID-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226716#comment-16226716
]
ASF subversion and git services commented on QPID-7994:
---
Commit f21917c7f7b4fb18aed650f00d8f6d8f874ecd2a 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=f21917c ]
QPID-7994: [Broker-J][AMQP 1.0] Fix compilation errors
> [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found'
> on attaching of unsubscribe links for global durable shared subscriptions
> --
>
> Key: QPID-7994
> URL: https://issues.apache.org/jira/browse/QPID-7994
> Project: Qpid
> Issue Type: Bug
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> As per [QPIDJMS-220|https://issues.apache.org/jira/browse/QPIDJMS-220]
> {quote}
> During unsubscribe, if a ClientID is set on the connection, a link named with
> the subscription name would be used to perform a 'null source lookup' for the
> subscription, as it is already for the existing non-shared durable
> subscriptions (see earlier for behaviour outline). If a ClientID is not set,
> the "|global" suffix will be added as shown previously..
> {quote}
> The current broker behaviour is not compliment with QPIDJMS-220. The broker
> create a new link instead of looking for existing link having name
> {{|global}} as suggested by QPIDJMS-220. For the new link,
> the local source is null. As result, 'not=found' error is reported.
> The broker should try to find an existing link in the link registry using
> link name only rather than name and a container ID as it does now. If link
> with given name is found, it should be used to recover the source. The broker
> should perform the search by link name only if {{SHARED}} capability is
> requested either on connection or attach itself as suggested by QPIDJMS-220:
> {quote}
> Additionally, while using connections that dont have a ClientID set, i.e
> using global shared susbcriptions, the link will have "shared" and "global"
> desired capabilities added as hints to the server that this is an attempt to
> attach to a 'global' shared subscription of the appropriate name derived from
> the link, aiding the server should no link with this name be known by it for
> the particular client container-id currently in use.
> {quote}
--
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-7994) [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' on attaching of unsubscribe links for global durable shared subscriptions
[
https://issues.apache.org/jira/browse/QPID-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7994.
--
Resolution: Fixed
Fix Version/s: qpid-java-broker-7.0.0
Lorenz and I worked together at the fix for the JIRA.
As per Lorenz's comments, the Broker does not recover the link as the link is
created by the different container. Instead, the Broker finds the previous Link
with the same name for global shared subscription and copies source from the
link
> [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found'
> on attaching of unsubscribe links for global durable shared subscriptions
> --
>
> Key: QPID-7994
> URL: https://issues.apache.org/jira/browse/QPID-7994
> Project: Qpid
> Issue Type: Bug
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> As per [QPIDJMS-220|https://issues.apache.org/jira/browse/QPIDJMS-220]
> {quote}
> During unsubscribe, if a ClientID is set on the connection, a link named with
> the subscription name would be used to perform a 'null source lookup' for the
> subscription, as it is already for the existing non-shared durable
> subscriptions (see earlier for behaviour outline). If a ClientID is not set,
> the "|global" suffix will be added as shown previously..
> {quote}
> The current broker behaviour is not compliment with QPIDJMS-220. The broker
> create a new link instead of looking for existing link having name
> {{|global}} as suggested by QPIDJMS-220. For the new link,
> the local source is null. As result, 'not=found' error is reported.
> The broker should try to find an existing link in the link registry using
> link name only rather than name and a container ID as it does now. If link
> with given name is found, it should be used to recover the source. The broker
> should perform the search by link name only if {{SHARED}} capability is
> requested either on connection or attach itself as suggested by QPIDJMS-220:
> {quote}
> Additionally, while using connections that dont have a ClientID set, i.e
> using global shared susbcriptions, the link will have "shared" and "global"
> desired capabilities added as hints to the server that this is an attempt to
> attach to a 'global' shared subscription of the appropriate name derived from
> the link, aiding the server should no link with this name be known by it for
> the particular client container-id currently in use.
> {quote}
--
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-7994) [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' on attaching of unsubscribe links for global durable shared subscriptions
[
https://issues.apache.org/jira/browse/QPID-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226686#comment-16226686
]
ASF subversion and git services commented on QPID-7994:
---
Commit 9502604d8c36eee079507da52e0e91b3c5c2e2d4 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=9502604 ]
QPID-7994: [Broker-J][AMQP 1.0] Allow link recovery of global durable shared
subscriptions
> [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found'
> on attaching of unsubscribe links for global durable shared subscriptions
> --
>
> Key: QPID-7994
> URL: https://issues.apache.org/jira/browse/QPID-7994
> Project: Qpid
> Issue Type: Bug
>Reporter: Alex Rudyy
>
> As per [QPIDJMS-220|https://issues.apache.org/jira/browse/QPIDJMS-220]
> {quote}
> During unsubscribe, if a ClientID is set on the connection, a link named with
> the subscription name would be used to perform a 'null source lookup' for the
> subscription, as it is already for the existing non-shared durable
> subscriptions (see earlier for behaviour outline). If a ClientID is not set,
> the "|global" suffix will be added as shown previously..
> {quote}
> The current broker behaviour is not compliment with QPIDJMS-220. The broker
> create a new link instead of looking for existing link having name
> {{|global}} as suggested by QPIDJMS-220. For the new link,
> the local source is null. As result, 'not=found' error is reported.
> The broker should try to find an existing link in the link registry using
> link name only rather than name and a container ID as it does now. If link
> with given name is found, it should be used to recover the source. The broker
> should perform the search by link name only if {{SHARED}} capability is
> requested either on connection or attach itself as suggested by QPIDJMS-220:
> {quote}
> Additionally, while using connections that dont have a ClientID set, i.e
> using global shared susbcriptions, the link will have "shared" and "global"
> desired capabilities added as hints to the server that this is an attempt to
> attach to a 'global' shared subscription of the appropriate name derived from
> the link, aiding the server should no link with this name be known by it for
> the particular client container-id currently in use.
> {quote}
--
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] (DISPATCH-862) have the CI build log detal which commit is being used from the Proton repo
Robbie Gemmell created DISPATCH-862: --- Summary: have the CI build log detal which commit is being used from the Proton repo Key: DISPATCH-862 URL: https://issues.apache.org/jira/browse/DISPATCH-862 Project: Qpid Dispatch Issue Type: Task Components: Tests Reporter: Robbie Gemmell Priority: Minor Not release-specific, just saving a thought I've had a couple times now. The Travis CI build job for Dispatch uses git submodules to pull in the proton repo and then builds it locally before building Dispatch. Other than estimating it based on the build times, I didn't see a way to establish what commit is actually used when this occurs. It might be nice if the build printed the commit details after setting up the submodule so that they are just available in the log without investigation work. -- 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-1669) 0.19.0 release tasks
Robbie Gemmell created PROTON-1669: -- Summary: 0.19.0 release tasks Key: PROTON-1669 URL: https://issues.apache.org/jira/browse/PROTON-1669 Project: Qpid Proton Issue Type: Task Components: proton-c, release Reporter: Robbie Gemmell Assignee: Robbie Gemmell 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
[jira] [Updated] (PROTON-1669) 0.19.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1669: --- Fix Version/s: (was: proton-c-0.18.1) proton-c-0.19.0 > 0.19.0 release tasks > > > Key: PROTON-1669 > URL: https://issues.apache.org/jira/browse/PROTON-1669 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.19.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] (PROTON-1668) 0.18.1 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1668: --- Fix Version/s: (was: proton-c-0.18.0) proton-c-0.18.1 > 0.18.1 release tasks > > > Key: PROTON-1668 > URL: https://issues.apache.org/jira/browse/PROTON-1668 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > 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
[jira] [Created] (PROTON-1668) 0.18.1 release tasks
Robbie Gemmell created PROTON-1668: -- Summary: 0.18.1 release tasks Key: PROTON-1668 URL: https://issues.apache.org/jira/browse/PROTON-1668 Project: Qpid Proton Issue Type: Task Components: proton-c, release Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: proton-c-0.18.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] (PROTON-1656) [OSX] c-proactor-tests test_ipv4_ipv6 fails
[
https://issues.apache.org/jira/browse/PROTON-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1656:
---
Fix Version/s: (was: proton-c-0.18.1)
proton-c-0.19.0
This isn't a regression, and its probably worth aligning it with work on making
the build/test suite more accepting of differences between the platforms,
setting up some CI for OSX if we are targeting the tests working there, etc.
Moving to the next release so 0.18.1 can proceed as originally planned.
> [OSX] c-proactor-tests test_ipv4_ipv6 fails
> ---
>
> Key: PROTON-1656
> URL: https://issues.apache.org/jira/browse/PROTON-1656
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: proton-c
> Environment: OSX 10.11.6, Xcode 7.3.1
>Reporter: Roddie Kieley
> Fix For: proton-c-0.19.0
>
>
> This fails almost 100% of the time, usually with the following:
> {code}
> 10: TEST: test_ipv4_ipv6()
> 10:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637:
> check failed: No condition, expected :refused [test_ipv4_ipv6()]
> 10:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:638:
> check failed: No condition, expected :refused [test_ipv4_ipv6()]
> 10: FAIL: test_ipv4_ipv6() (2 errors)
> {code}
> or
> {code}
> 10: TEST: test_ipv4_ipv6()
> 10:
> /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637:
> check failed: 'refused' not in 'connection timed out - connecting to
> 127.0.0.1:49446' [test_ipv4_ipv6()]
> 10: FAIL: test_ipv4_ipv6() (1 errors)
> {code}
> It passed once during testing yesterday but not sure what that is indicative
> of yet. Tested on Fedora 25 and always passes. Note that Fedora 25 is on a
> separate box and I do note that the OSX box has two 'inactive' entries in
> ifconfig which may or may not interfere with binding to 0.0.0.0 or ::1:
> {code}
> earth:126 rkieley$ ifconfig
> lo0: flags=8049 mtu 16384
> options=3
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff00
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> nd6 options=1
> gif0: flags=8010 mtu 1280
> stf0: flags=0<> mtu 1280
> en0: flags=8863 mtu 1500
> options=27
> ether d4:9a:20:0d:67:fc
> inet6 fe80::d69a:20ff:fe0d:67fc%en0 prefixlen 64 scopeid 0x4
> inet 192.168.2.4 netmask 0xff00 broadcast 192.168.2.255
> nd6 options=1
> media: autoselect (1000baseT )
> status: active
> en1: flags=8823 mtu 1500
> ether f8:1e:df:f4:46:8c
> nd6 options=1
> media: autoselect ()
> status: inactive
> fw0: flags=8863 mtu 494
> lladdr d4:9a:20:ff:fe:0d:67:fc
> nd6 options=1
> media: autoselect
> status: inactive
> earth:126 rkieley$
> {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-1666) Erroneous fix for PROTON-1616 would trim final character of ANONYMOUS username
[ https://issues.apache.org/jira/browse/PROTON-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226637#comment-16226637 ] Robbie Gemmell commented on PROTON-1666: Full details for the above commit: Commit de3fd617210b5d5a2f2c3e384c33905dbf75ad58 in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=de3fd61 ] PROTON-1616: Revert erroneous fix for coverity false positive > Erroneous fix for PROTON-1616 would trim final character of ANONYMOUS username > -- > > Key: PROTON-1666 > URL: https://issues.apache.org/jira/browse/PROTON-1666 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Minor > Fix For: proton-c-0.18.1 > > > This fix for a coverity false positive, would have the affect of trimming the > last character the username specified for an anonymous user in the default > (non cyrus) sasl implementation. -- 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-1616) Review and fix Coverity issues for Proton
[ https://issues.apache.org/jira/browse/PROTON-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226636#comment-16226636 ] Robbie Gemmell commented on PROTON-1616: The last commit should attribute PROTON-1666 as well or instead, and is part of 0.18.1 rather than 0.18.0. > Review and fix Coverity issues for Proton > - > > Key: PROTON-1616 > URL: https://issues.apache.org/jira/browse/PROTON-1616 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.18.0 > > > See coverity report at https://scan4.coverity.com/reports.htm#v14283/p10556 -- 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-1654) Windows build does not compile the examples that require C++11
[ https://issues.apache.org/jira/browse/PROTON-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1654: --- Fix Version/s: (was: proton-c-0.18.1) proton-c-0.19.0 > Windows build does not compile the examples that require C++11 > -- > > Key: PROTON-1654 > URL: https://issues.apache.org/jira/browse/PROTON-1654 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.19.0 > > > * scheduled_send > * multithreaded_client > * multithreaded_client_flow_control > Do not get built on Windows because C++11 examples are explicitly excluded > there. -- 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-1654) Windows build does not compile the examples that require C++11
[ https://issues.apache.org/jira/browse/PROTON-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226569#comment-16226569 ] Robbie Gemmell commented on PROTON-1654: Some other commits toward 0.18.1 look to have touched the periphery of these bits, but I'm not clear whether its still the case that they don't get built on Windows. In any case, this is marked as an improvement and the example code itself being present is really the main thing for now, so if this wasn't done indirectly already then it can wait for the next release so that 0.18.1 can proceed as planned. I'll bump the fix-version to 0.19.0 for now, and we can update it later as appropriate. > Windows build does not compile the examples that require C++11 > -- > > Key: PROTON-1654 > URL: https://issues.apache.org/jira/browse/PROTON-1654 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.19.0 > > > * scheduled_send > * multithreaded_client > * multithreaded_client_flow_control > Do not get built on Windows because C++11 examples are explicitly excluded > there. -- 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-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 ] Robbie Gemmell updated PROTON-1603: --- Fix Version/s: (was: proton-c-0.18.1) Dropping the fix-version since it was closed as duplicate and appears nothing was done against the JIRA other than raising a replacement. > 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 > > 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] [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 ] Robbie Gemmell 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 > > 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 ] Robbie Gemmell 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] [Resolved] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-7399.
--
Resolution: Fixed
> [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
