[jira] [Commented] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943261#comment-16943261 ] Roddie Kieley commented on PROTON-2105: --- Thanks for the details and direction [~aconway]! Perhaps I should have read the readme sooner as I had completely forgotten any of the details I had previously known about the magic branch. Will proceed to prepare the re-organization and go 1.12 based go.mod file as above along with any build related changes as required. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration
[ https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943177#comment-16943177 ] ASF subversion and git services commented on DISPATCH-1418: --- Commit fc9c4380d796656ad964e04bb389d3223d94b1c5 in qpid-dispatch's branch refs/heads/master from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=fc9c438 ] DISPATCH-1418: use proper outcome for deliveries to unavailable addresses Use the configured address treatment if available. Otherwise use the router default treatment. This closes #579 > The default forwarding treatment is not overridden by the treatment in the > address configuration > > > Key: DISPATCH-1418 > URL: https://issues.apache.org/jira/browse/DISPATCH-1418 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > When a message cannot be forwarded the message should be released. > However, when the forwarding treatment is "unavailable" that message must be > REJECTED (as per the description of the "unavailable" treatment). > When the router tries to determine if the outcome should be RELEASED or > REJECTED it does not check for a matching router.config.address configuration > entity. This entity contains a treatment for the given address. If an > address configuration matches the address the treatment should come from the > address configuration - not the router default configuration. > To reproduce: > Configure a router with defaultTreatment set to unavailable. > Configure an address prefix that uses the "closest" treatment. > Attach a sender to the router using an anonymous link. > Send a message to an address that will match the configured address prefix > while there are no subscribers. > Expect: the message be RELEASED by the router > Actual: the message is REJECTED by the router -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration
[ https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943178#comment-16943178 ] ASF GitHub Bot commented on DISPATCH-1418: -- asfgit commented on pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre… URL: https://github.com/apache/qpid-dispatch/pull/579 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > The default forwarding treatment is not overridden by the treatment in the > address configuration > > > Key: DISPATCH-1418 > URL: https://issues.apache.org/jira/browse/DISPATCH-1418 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > When a message cannot be forwarded the message should be released. > However, when the forwarding treatment is "unavailable" that message must be > REJECTED (as per the description of the "unavailable" treatment). > When the router tries to determine if the outcome should be RELEASED or > REJECTED it does not check for a matching router.config.address configuration > entity. This entity contains a treatment for the given address. If an > address configuration matches the address the treatment should come from the > address configuration - not the router default configuration. > To reproduce: > Configure a router with defaultTreatment set to unavailable. > Configure an address prefix that uses the "closest" treatment. > Attach a sender to the router using an anonymous link. > Send a message to an address that will match the configured address prefix > while there are no subscribers. > Expect: the message be RELEASED by the router > Actual: the message is REJECTED by the router -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre…
asfgit closed pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre… URL: https://github.com/apache/qpid-dispatch/pull/579 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration
[ https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-1418: - Description: When a message cannot be forwarded the message should be released. However, when the forwarding treatment is "unavailable" that message must be REJECTED (as per the description of the "unavailable" treatment). When the router tries to determine if the outcome should be RELEASED or REJECTED it does not check for a matching router.config.address configuration entity. This entity contains a treatment for the given address. If an address configuration matches the address the treatment should come from the address configuration - not the router default configuration. To reproduce: Configure a router with defaultTreatment set to unavailable. Configure an address prefix that uses the "closest" treatment. Attach a sender to the router using an anonymous link. Send a message to an address that will match the configured address prefix while there are no subscribers. Expect: the message be RELEASED by the router Actual: the message is REJECTED by the router was: When a message cannot be forwarded the message should be released. However, when the forwarding treatment is "unavailable" that message must be REJECTED (as per the description of the "unavailable treatment). When the router tries to determine if the outcome should be RELEASED or REJECTED it does not check for a matching router.config.address configuration entity. This entity contains a treatment for the given address. If an address configuration matches the address the treatment should come from the address configuration - not the router default configuration. To reproduce: Configure a router with defaultTreatment set to unavailable. Configure an address prefix that uses the "closest" treatment. Attach a sender to the router using an anonymous link. Send a message to an address that will match the configured address prefix while there are no subscribers. Expect: the message be RELEASED by the router Actual: the message is REJECTED by the router > The default forwarding treatment is not overridden by the treatment in the > address configuration > > > Key: DISPATCH-1418 > URL: https://issues.apache.org/jira/browse/DISPATCH-1418 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > When a message cannot be forwarded the message should be released. > However, when the forwarding treatment is "unavailable" that message must be > REJECTED (as per the description of the "unavailable" treatment). > When the router tries to determine if the outcome should be RELEASED or > REJECTED it does not check for a matching router.config.address configuration > entity. This entity contains a treatment for the given address. If an > address configuration matches the address the treatment should come from the > address configuration - not the router default configuration. > To reproduce: > Configure a router with defaultTreatment set to unavailable. > Configure an address prefix that uses the "closest" treatment. > Attach a sender to the router using an anonymous link. > Send a message to an address that will match the configured address prefix > while there are no subscribers. > Expect: the message be RELEASED by the router > Actual: the message is REJECTED by the router -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration
[ https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-1418: - Description: When a message cannot be forwarded the message should be released. However, when the forwarding treatment is "unavailable" that message must be REJECTED (as per the description of the "unavailable treatment). When the router tries to determine if the outcome should be RELEASED or REJECTED it does not check for a matching router.config.address configuration entity. This entity contains a treatment for the given address. If an address configuration matches the address the treatment should come from the address configuration - not the router default configuration. To reproduce: Configure a router with defaultTreatment set to unavailable. Configure an address prefix that uses the "closest" treatment. Attach a sender to the router using an anonymous link. Send a message to an address that will match the configured address prefix while there are no subscribers. Expect: the message be RELEASED by the router Actual: the message is REJECTED by the router was: Attach a sender to the router using an anonymous link. Send a message to an address that is pre-configured (say "closest/foo") while there are no subscribers. Expect: the message be RELEASED by the router Actual: the message is REJECTED by the router See system_tests_router_mesh.py > The default forwarding treatment is not overridden by the treatment in the > address configuration > > > Key: DISPATCH-1418 > URL: https://issues.apache.org/jira/browse/DISPATCH-1418 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > When a message cannot be forwarded the message should be released. > However, when the forwarding treatment is "unavailable" that message must be > REJECTED (as per the description of the "unavailable treatment). > When the router tries to determine if the outcome should be RELEASED or > REJECTED it does not check for a matching router.config.address configuration > entity. This entity contains a treatment for the given address. If an > address configuration matches the address the treatment should come from the > address configuration - not the router default configuration. > To reproduce: > Configure a router with defaultTreatment set to unavailable. > Configure an address prefix that uses the "closest" treatment. > Attach a sender to the router using an anonymous link. > Send a message to an address that will match the configured address prefix > while there are no subscribers. > Expect: the message be RELEASED by the router > Actual: the message is REJECTED by the router -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration
[ https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-1418: - Summary: The default forwarding treatment is not overridden by the treatment in the address configuration (was: sending a msg to a configured address w/o subscribers should RELEASE not REJECT) > The default forwarding treatment is not overridden by the treatment in the > address configuration > > > Key: DISPATCH-1418 > URL: https://issues.apache.org/jira/browse/DISPATCH-1418 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Attach a sender to the router using an anonymous link. > Send a message to an address that is pre-configured (say "closest/foo") while > there are no subscribers. > Expect: the message be RELEASED by the router > Actual: the message is REJECTED by the router > See system_tests_router_mesh.py -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1327) Router stops forwarding multicast deliveries (large messages) to connected receivers after a receiver closes its connection
[ https://issues.apache.org/jira/browse/DISPATCH-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1327. -- Resolution: Cannot Reproduce I have not been able to repro this with the latest master (10/02/2019). If this problem is still present please re-open this bug. > Router stops forwarding multicast deliveries (large messages) to connected > receivers after a receiver closes its connection > --- > > Key: DISPATCH-1327 > URL: https://issues.apache.org/jira/browse/DISPATCH-1327 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.7.0 >Reporter: Fernando Giorgetti >Assignee: Ken Giusti >Priority: Major > > The problem can be observed running > *test_40_drop_rx_client_multicast_large_message*** from > *system_tests_edge_router*. > It does not happen all the time, but after some attempts it will fail and we > can observe receivers won't get all sent messages and then test times out. > Further info to be attached. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1431) system_tests_one_router_failing on test_19_semantics_multicast
[ https://issues.apache.org/jira/browse/DISPATCH-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1431. -- Resolution: Fixed > system_tests_one_router_failing on test_19_semantics_multicast > -- > > Key: DISPATCH-1431 > URL: https://issues.apache.org/jira/browse/DISPATCH-1431 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ken Giusti >Priority: Major > Fix For: 1.10.0 > > > Turn on valgrind and compile the router code. > {noformat} > make clean > cmake .. -DUSE_VALGRIND=Yes -DVALGRIND_XML=Yes > make install{noformat} > Then run test_19_semantics_multicast > {noformat} > [gmurthy@localhost build]$ /usr/bin/python > "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" > "-v" "system_tests_one_router.OneRouterTest.test_19_semantics_multicast" > test_19_semantics_multicast (system_tests_one_router.OneRouterTest) ... > FAIL== > FAIL: test_19_semantics_multicast (system_tests_one_router.OneRouterTest) > -- > Traceback (most recent call last): > File > "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_one_router.py", > line 264, in test_19_semantics_multicast > self.assertEqual(None, test.error) > AssertionError: None != u'Timeout Expired: sent=1 > rcvd=0/1/0'-- > Ran 1 test in 65.460sFAILED (failures=1) > [gmurthy@localhost build]$ > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1431) system_tests_one_router_failing on test_19_semantics_multicast
[ https://issues.apache.org/jira/browse/DISPATCH-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943155#comment-16943155 ] ASF subversion and git services commented on DISPATCH-1431: --- Commit ff971d416bc20048f0576176b54c36ef7ebcea38 in qpid-dispatch's branch refs/heads/master from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=ff971d4 ] DISPATCH-1431: fix system_tests_one_router multicast test client race > system_tests_one_router_failing on test_19_semantics_multicast > -- > > Key: DISPATCH-1431 > URL: https://issues.apache.org/jira/browse/DISPATCH-1431 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ken Giusti >Priority: Major > Fix For: 1.10.0 > > > Turn on valgrind and compile the router code. > {noformat} > make clean > cmake .. -DUSE_VALGRIND=Yes -DVALGRIND_XML=Yes > make install{noformat} > Then run test_19_semantics_multicast > {noformat} > [gmurthy@localhost build]$ /usr/bin/python > "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" > "-v" "system_tests_one_router.OneRouterTest.test_19_semantics_multicast" > test_19_semantics_multicast (system_tests_one_router.OneRouterTest) ... > FAIL== > FAIL: test_19_semantics_multicast (system_tests_one_router.OneRouterTest) > -- > Traceback (most recent call last): > File > "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_one_router.py", > line 264, in test_19_semantics_multicast > self.assertEqual(None, test.error) > AssertionError: None != u'Timeout Expired: sent=1 > rcvd=0/1/0'-- > Ran 1 test in 65.460sFAILED (failures=1) > [gmurthy@localhost build]$ > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1431) system_tests_one_router_failing on test_19_semantics_multicast
[ https://issues.apache.org/jira/browse/DISPATCH-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943130#comment-16943130 ] Ken Giusti commented on DISPATCH-1431: -- This is a race condition on the test itself: The sender is sending it's one test message before all receivers have completed attaching. So the multicast only goes to one or two clients and the test times out since it is waiting for all three receivers to get a copy. > system_tests_one_router_failing on test_19_semantics_multicast > -- > > Key: DISPATCH-1431 > URL: https://issues.apache.org/jira/browse/DISPATCH-1431 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ken Giusti >Priority: Major > Fix For: 1.10.0 > > > Turn on valgrind and compile the router code. > {noformat} > make clean > cmake .. -DUSE_VALGRIND=Yes -DVALGRIND_XML=Yes > make install{noformat} > Then run test_19_semantics_multicast > {noformat} > [gmurthy@localhost build]$ /usr/bin/python > "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" > "-v" "system_tests_one_router.OneRouterTest.test_19_semantics_multicast" > test_19_semantics_multicast (system_tests_one_router.OneRouterTest) ... > FAIL== > FAIL: test_19_semantics_multicast (system_tests_one_router.OneRouterTest) > -- > Traceback (most recent call last): > File > "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_one_router.py", > line 264, in test_19_semantics_multicast > self.assertEqual(None, test.error) > AssertionError: None != u'Timeout Expired: sent=1 > rcvd=0/1/0'-- > Ran 1 test in 65.460sFAILED (failures=1) > [gmurthy@localhost build]$ > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1418) sending a msg to a configured address w/o subscribers should RELEASE not REJECT
[ https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943123#comment-16943123 ] ASF GitHub Bot commented on DISPATCH-1418: -- kgiusti commented on pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre… URL: https://github.com/apache/qpid-dispatch/pull/579 …sses Use the configured address treatment if available. Otherwise use the router default treatment. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > sending a msg to a configured address w/o subscribers should RELEASE not > REJECT > --- > > Key: DISPATCH-1418 > URL: https://issues.apache.org/jira/browse/DISPATCH-1418 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0, 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Attach a sender to the router using an anonymous link. > Send a message to an address that is pre-configured (say "closest/foo") while > there are no subscribers. > Expect: the message be RELEASED by the router > Actual: the message is REJECTED by the router > See system_tests_router_mesh.py -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] kgiusti opened a new pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre…
kgiusti opened a new pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre… URL: https://github.com/apache/qpid-dispatch/pull/579 …sses Use the configured address treatment if available. Otherwise use the router default treatment. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1399) Allow arrows on console's topology page to be disabled
[ https://issues.apache.org/jira/browse/DISPATCH-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1399. Fix Version/s: 1.10.0 Resolution: Implemented > Allow arrows on console's topology page to be disabled > -- > > Key: DISPATCH-1399 > URL: https://issues.apache.org/jira/browse/DISPATCH-1399 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.8.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.10.0 > > > The topology diagram shows the direction that connections are initiated. The > router with the listener has the arrow pointing to it. > This can be confusing since there is actually bi-directional traffic going > over the connection's links. > There should be an option to hide the arrows. > The arrows should be hidden by default. > The current state of the arrows (visible/hidden) should be remembered (per > browser) and restored. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated DISPATCH-1434: Reporter: Ganesh Murthy (was: gmurthy-foo) > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile
[ https://issues.apache.org/jira/browse/DISPATCH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated DISPATCH-1436: Reporter: Ganesh Murthy (was: gmurthy-foo) > Don't allow both password and passwordFile to be specified in sslProfile > -- > > Key: DISPATCH-1436 > URL: https://issues.apache.org/jira/browse/DISPATCH-1436 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container, Management Agent >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: gmurthy-foo >Priority: Major > > Currently, the password field takes precedence over passwordFile when both > are specified in the sslProfile entity. > The router should not start if both are specified. > qdmanage commands specifying both must result in Bad Request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1433) system_tests_delivery_abort failing due to receiver connecting late
[ https://issues.apache.org/jira/browse/DISPATCH-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas reassigned DISPATCH-1433: --- Assignee: Ganesh Murthy (was: gmurthy-foo) > system_tests_delivery_abort failing due to receiver connecting late > --- > > Key: DISPATCH-1433 > URL: https://issues.apache.org/jira/browse/DISPATCH-1433 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.9.0 >Reporter: gmurthy-foo >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > > {noformat} > "40: test_07_multicast_truncate_one_router > (system_tests_delivery_abort.RouterTest) ... FAIL", > "40: ", > "40: > ==", > "40: FAIL: test_07_multicast_truncate_one_router > (system_tests_delivery_abort.RouterTest)", > "40: > --", > "40: Traceback (most recent call last):", > "40: File > \"/opt/qpid-dispatch-src/tests/system_tests_delivery_abort.py\", line 127, in > test_07_multicast_truncate_one_router", > "40: self.assertEqual(None, test.error)", > "40: AssertionError: None != u\"Expected: [u'Send_Short_1', > u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', > u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', > u'3', u'Send_Short_3'], Actuals: [u'Aborted_Delivery', u'2', u'2', u'2', > u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'Send_Short_2', u'3', u'3', u'3', > u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'Send_Short_3'], [u'Send_Short_1', > u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', > u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', > u'3', u'Send_Short_3']\"", > "40: ", > "40: > --", > "40: Ran 7 tests in 15.769s", > "40: ", > "40: FAILED (failures=1)", > "40/59 Test #40: system_tests_delivery_abort > ...***Failed 15.93 sec", > "test 41", {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1433) system_tests_delivery_abort failing due to receiver connecting late
[ https://issues.apache.org/jira/browse/DISPATCH-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated DISPATCH-1433: Reporter: Ganesh Murthy (was: gmurthy-foo) > system_tests_delivery_abort failing due to receiver connecting late > --- > > Key: DISPATCH-1433 > URL: https://issues.apache.org/jira/browse/DISPATCH-1433 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > > {noformat} > "40: test_07_multicast_truncate_one_router > (system_tests_delivery_abort.RouterTest) ... FAIL", > "40: ", > "40: > ==", > "40: FAIL: test_07_multicast_truncate_one_router > (system_tests_delivery_abort.RouterTest)", > "40: > --", > "40: Traceback (most recent call last):", > "40: File > \"/opt/qpid-dispatch-src/tests/system_tests_delivery_abort.py\", line 127, in > test_07_multicast_truncate_one_router", > "40: self.assertEqual(None, test.error)", > "40: AssertionError: None != u\"Expected: [u'Send_Short_1', > u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', > u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', > u'3', u'Send_Short_3'], Actuals: [u'Aborted_Delivery', u'2', u'2', u'2', > u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'Send_Short_2', u'3', u'3', u'3', > u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'Send_Short_3'], [u'Send_Short_1', > u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', > u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', > u'3', u'Send_Short_3']\"", > "40: ", > "40: > --", > "40: Ran 7 tests in 15.769s", > "40: ", > "40: FAILED (failures=1)", > "40/59 Test #40: system_tests_delivery_abort > ...***Failed 15.93 sec", > "test 41", {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile
[ https://issues.apache.org/jira/browse/DISPATCH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas reassigned DISPATCH-1436: --- Assignee: Ganesh Murthy (was: gmurthy-foo) > Don't allow both password and passwordFile to be specified in sslProfile > -- > > Key: DISPATCH-1436 > URL: https://issues.apache.org/jira/browse/DISPATCH-1436 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container, Management Agent >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Currently, the password field takes precedence over passwordFile when both > are specified in the sslProfile entity. > The router should not start if both are specified. > qdmanage commands specifying both must result in Bad Request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1437) TEST ISSUE CREATION - WILL CLOSE THIS
[ https://issues.apache.org/jira/browse/DISPATCH-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy closed DISPATCH-1437. --- > TEST ISSUE CREATION - WILL CLOSE THIS > - > > Key: DISPATCH-1437 > URL: https://issues.apache.org/jira/browse/DISPATCH-1437 > Project: Qpid Dispatch > Issue Type: Task > Components: Management Agent >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1437) TEST ISSUE CREATION - WILL CLOSE THIS
Ganesh Murthy created DISPATCH-1437: --- Summary: TEST ISSUE CREATION - WILL CLOSE THIS Key: DISPATCH-1437 URL: https://issues.apache.org/jira/browse/DISPATCH-1437 Project: Qpid Dispatch Issue Type: Task Components: Management Agent Affects Versions: 1.9.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Fix For: 1.10.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1437) TEST ISSUE CREATION - WILL CLOSE THIS
[ https://issues.apache.org/jira/browse/DISPATCH-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1437. - Resolution: Invalid > TEST ISSUE CREATION - WILL CLOSE THIS > - > > Key: DISPATCH-1437 > URL: https://issues.apache.org/jira/browse/DISPATCH-1437 > Project: Qpid Dispatch > Issue Type: Task > Components: Management Agent >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-1434: --- Assignee: Ganesh Murthy (was: gmurthy#1) > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: gmurthy#1 >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8364) [Broker-J] Add support for SPNEGO authentication into HTTP management
[ https://issues.apache.org/jira/browse/QPID-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943028#comment-16943028 ] ASF subversion and git services commented on QPID-8364: --- Commit 748ec6880feb2f25242586332937e299aee0f485 in qpid-broker-j's branch refs/heads/7.1.x from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=748ec68 ] QPID-8364: [Broker-J] Fix tests (cherry picked from commit 19ad881bf2297742ac5aff7a1538277464550df0) > [Broker-J] Add support for SPNEGO authentication into HTTP management > - > > Key: QPID-8364 > URL: https://issues.apache.org/jira/browse/QPID-8364 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5 > > > The Kerberos Authentication is only supported for messaging connections. The > support for Kerberos SPENEGO Authentication needs to be implemented for HTTP > management. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8364) [Broker-J] Add support for SPNEGO authentication into HTTP management
[ https://issues.apache.org/jira/browse/QPID-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943027#comment-16943027 ] ASF subversion and git services commented on QPID-8364: --- Commit 19ad881bf2297742ac5aff7a1538277464550df0 in qpid-broker-j's branch refs/heads/master from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=19ad881 ] QPID-8364: [Broker-J] Fix tests > [Broker-J] Add support for SPNEGO authentication into HTTP management > - > > Key: QPID-8364 > URL: https://issues.apache.org/jira/browse/QPID-8364 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5 > > > The Kerberos Authentication is only supported for messaging connections. The > support for Kerberos SPENEGO Authentication needs to be implemented for HTTP > management. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8357) [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative property 'sole-connection-eforcement-policy' when 'close-existing' eforcement policy is requested
[ https://issues.apache.org/jira/browse/QPID-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942987#comment-16942987 ] ASF subversion and git services commented on QPID-8357: --- Commit 5589cd139515fbb1e3a73911c30e3ea235c7b3a6 in qpid-broker-j's branch refs/heads/7.1.x from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=5589cd1 ] QPID-8357: [Broker-J][AMQP 1.0][Sole connection] Broker should set open property 'sole-connection-eforcement-policy' when 'close-existing' eforcement policy is requested (cherry picked from commit c4fae61eb8d89c9b20122e75691307ce82a8aaeb) > [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative > property 'sole-connection-eforcement-policy' when 'close-existing' eforcement > policy is requested > - > > Key: QPID-8357 > URL: https://issues.apache.org/jira/browse/QPID-8357 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.4 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5 > > > Broker should set {{open}} performative property > {{sole-connection-eforcement-policy'}} when {{close-existing}} eforcement > policy is requested. Otherwise, peer might assume that policy > {{refuse-connection}} is used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8357) [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative property 'sole-connection-eforcement-policy' when 'close-existing' eforcement policy is requested
[ https://issues.apache.org/jira/browse/QPID-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8357: - Fix Version/s: qpid-java-broker-8.0.0 > [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative > property 'sole-connection-eforcement-policy' when 'close-existing' eforcement > policy is requested > - > > Key: QPID-8357 > URL: https://issues.apache.org/jira/browse/QPID-8357 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.4 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5 > > > Broker should set {{open}} performative property > {{sole-connection-eforcement-policy'}} when {{close-existing}} eforcement > policy is requested. Otherwise, peer might assume that policy > {{refuse-connection}} is used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] gemmellr commented on issue #194: ENTMQCL-1062:[CMake] Fixing an issue with cmake not compiling c++11 e…
gemmellr commented on issue #194: ENTMQCL-1062:[CMake] Fixing an issue with cmake not compiling c++11 e… URL: https://github.com/apache/qpid-proton/pull/194#issuecomment-537572146 Can you please [raise and/or] reference a PROTON Jira key in your PR titles and commit logs. https://issues.apache.org/jira/projects/PROTON This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1434. - Fix Version/s: 1.10.0 Resolution: Fixed > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.10.0 > > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942944#comment-16942944 ] ASF GitHub Bot commented on DISPATCH-1434: -- asfgit commented on pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942943#comment-16942943 ] ASF subversion and git services commented on DISPATCH-1434: --- Commit a97dea9aace6142d58f70caf66710386dc3e1156 in qpid-dispatch's branch refs/heads/master from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=a97dea9 ] DISPATCH-1434 - Added new attribute saslPasswordFile to the connector entity. saslPassword entity has been deprecated. This closes #578. > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
asfgit closed pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J
[ https://issues.apache.org/jira/browse/QPID-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942940#comment-16942940 ] ASF subversion and git services commented on QPID-8361: --- Commit a5453d5b05a0c4fdb12da36410917145e518ef30 in qpid-broker-j's branch refs/heads/master from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=a5453d5 ] QPID-8361: [Broker-J] Update TOC > [Broker-J] Create a developer guide for Qpid Broker-J > - > > Key: QPID-8361 > URL: https://issues.apache.org/jira/browse/QPID-8361 > Project: Qpid > Issue Type: Task > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > The developer documentation is currently scattered over various Qpid > confluence pages. It could be challenging for people interested in > contributing to the project to find that documentation. A developer guide > could be added to cover such aspects as > * Environment Setup > * Building project > * Running tests > * Releasing > * Architecture overview > The following wiki pages are good candidates for inclusion into a developer > guide: > [High Level > Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture] > [How To Build Qpid > Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J] > [Releasing Qpid > Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J] > The wiki pages below might be included as well > [Java Coding > Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards] > [Qpid Java Run > Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts] > The developer documentation should be easy to modify, maintain and preview. > Thus, it can be written in markdown or > [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The > latter is also supported on github. > Potentially, it can be published on Qpid project site as part of release > process. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J
[ https://issues.apache.org/jira/browse/QPID-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942938#comment-16942938 ] ASF subversion and git services commented on QPID-8361: --- Commit fb0d8b9b7981a890d31e037e9f3157b11ef44c2f in qpid-broker-j's branch refs/heads/master from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=fb0d8b9 ] QPID-8361: [Broker-J] Add description for ACL model > [Broker-J] Create a developer guide for Qpid Broker-J > - > > Key: QPID-8361 > URL: https://issues.apache.org/jira/browse/QPID-8361 > Project: Qpid > Issue Type: Task > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > The developer documentation is currently scattered over various Qpid > confluence pages. It could be challenging for people interested in > contributing to the project to find that documentation. A developer guide > could be added to cover such aspects as > * Environment Setup > * Building project > * Running tests > * Releasing > * Architecture overview > The following wiki pages are good candidates for inclusion into a developer > guide: > [High Level > Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture] > [How To Build Qpid > Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J] > [Releasing Qpid > Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J] > The wiki pages below might be included as well > [Java Coding > Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards] > [Qpid Java Run > Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts] > The developer documentation should be easy to modify, maintain and preview. > Thus, it can be written in markdown or > [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The > latter is also supported on github. > Potentially, it can be published on Qpid project site as part of release > process. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942919#comment-16942919 ] Alan Conway edited comment on PROTON-2105 at 10/2/19 4:05 PM: -- Yep, I started looking at that before I was dragged off elsewhere. There's a history of my blunders here: # The directory layout is wrong: `go/src/qpid.apache.org/` is laid out like a workspace, not a project. Classic newbie mistake by me long ago and never corrected. # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and some redirecting metadata tags on the qpid.apache.org website. The release process to update the go1 branch is explained here: [https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1] The magic go1 branch and HTTP redirect is nowadays deprecated in favour of modules, we should get rid of it. First re-organize the directory tree to be `proton/go/pkg/...` - as we're changing package name we should take the chance to clean up. Now go/go.mod is simply: {code} module github.com/apache/qpid-proton/go go 1.12 {code} (I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including Fedora 30) The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc. I would do all of the above in a single release cycle and leave the qpid.apache.org redirect stuck at the last release. That way existing users won't be broken, new users use the new names. It is possible we could make the qpid.apache.org/... names continue to work, but I think it's better to make a clean break. The redirect-via-website is bewildering compared to the straightforward "package-name-equals-git-repo" convention which allows developers to easily find the source code, godocs etc. was (Author: aconway): Yep, I started looking at that before I was dragged off elsewhere. There's a history of my blunders here: # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid out like a workspace, not a project. Classic newbie mistake by me long ago and never corrected. # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and some redirecting metadata tags on the qpid.apache.org website. The release process to update the go1 branch is explained here: [https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1] The magic go1 branch and HTTP redirect is nowadays deprecated in favour of modules, we should get rid of it. We have to change the package names, so we want to get it right the first time :) First re-organize the directory tree to be `proton/go/pkg/...` - as we're changing package name we should take the chance to clean up. Now go/go.mod is simply: {code} module github.com/apache/qpid-proton/go go 1.12 {code} (I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including Fedora 30) The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc. I would do all of the above in a single release cycle and leave the qpid.apache.org redirect stuck at the current release. That way existing users won't be broken, new users use the new names. It is possible we could make the qpid.apache.org/... names continue to work, but I think it's better to make a clean break. The redirect-via-website is bewildering compared to the straightforward "package-name-equals-git-repo" convention which allows developers to easily find the source code, godocs etc. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942919#comment-16942919 ] Alan Conway edited comment on PROTON-2105 at 10/2/19 4:04 PM: -- Yep, I started looking at that before I was dragged off elsewhere. There's a history of my blunders here: # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid out like a workspace, not a project. Classic newbie mistake by me long ago and never corrected. # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and some redirecting metadata tags on the qpid.apache.org website. The release process to update the go1 branch is explained here: [https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1] The magic go1 branch and HTTP redirect is nowadays deprecated in favour of modules, we should get rid of it. We have to change the package names, so we want to get it right the first time :) First re-organize the directory tree to be `proton/go/pkg/...` - as we're changing package name we should take the chance to clean up. Now go/go.mod is simply: {code} module github.com/apache/qpid-proton/go go 1.12 {code} (I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including Fedora 30) The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc. I would do all of the above in a single release cycle and leave the qpid.apache.org redirect stuck at the current release. That way existing users won't be broken, new users use the new names. It is possible we could make the qpid.apache.org/... names continue to work, but I think it's better to make a clean break. The redirect-via-website is bewildering compared to the straightforward "package-name-equals-git-repo" convention which allows developers to easily find the source code, godocs etc. was (Author: aconway): Yep, I started looking at that before I was dragged off elsewhere. There's a history of my blunders here: # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid out like a workspace, not a project. Classic newbie mistake by me long ago and never corrected. # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and some redirecting metadata tags on the qpid.apache.org website. The release process to update the go1 branch is explained here: [https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1] The magic go1 branch and HTTP redirect is nowadays deprecated in favour of modules, we should get rid of it. We have to change the package names, so we want to get it right the first time :) Steps: # Re-organize the directory tree to be `proton/go/pkg/...` otherwise we'll have horrid long package names. # Pick a hostname: github.com or gitbox.apache.org. It's a political decision - github is more visible, but someone should check if apache policy requires the word "apache" in the "official" package names. I'm staying out of it. # Once the decision is made it's easy - assuming we choose github and re-organize the directories as above it would be: {code:java} module github.com/qpid-proton/go/ go 1.12 {code} (I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including Fedora 30) I would do all of the above in a single release cycle and leave the qpid.apache.org redirect stuck at the current release. That way existing users won't be broken, new users use the new names. It is possible we could make the qpid.apache.org/... names continue to work, but I think it's better to make a clean break. The redirect-via-website is bewildering compared to the straightforward "package-name-equals-git-repo" convention which allows developers to easily find the source code, godocs etc. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile
[ https://issues.apache.org/jira/browse/DISPATCH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942936#comment-16942936 ] Ganesh Murthy commented on DISPATCH-1436: - This applies for saslPassword and saslPasswordFile as well. > Don't allow both password and passwordFile to be specified in sslProfile > -- > > Key: DISPATCH-1436 > URL: https://issues.apache.org/jira/browse/DISPATCH-1436 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container, Management Agent >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Currently, the password field takes precedence over passwordFile when both > are specified in the sslProfile entity. > The router should not start if both are specified. > qdmanage commands specifying both must result in Bad Request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile
Ganesh Murthy created DISPATCH-1436: --- Summary: Don't allow both password and passwordFile to be specified in sslProfile Key: DISPATCH-1436 URL: https://issues.apache.org/jira/browse/DISPATCH-1436 Project: Qpid Dispatch Issue Type: Improvement Components: Container, Management Agent Affects Versions: 1.9.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Currently, the password field takes precedence over passwordFile when both are specified in the sslProfile entity. The router should not start if both are specified. qdmanage commands specifying both must result in Bad Request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942919#comment-16942919 ] Alan Conway commented on PROTON-2105: - Yep, I started looking at that before I was dragged off elsewhere. There's a history of my blunders here: # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid out like a workspace, not a project. Classic newbie mistake by me long ago and never corrected. # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and some redirecting metadata tags on the qpid.apache.org website. The release process to update the go1 branch is explained here: [https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1] The magic go1 branch and HTTP redirect is nowadays deprecated in favour of modules, we should get rid of it. We have to change the package names, so we want to get it right the first time :) Steps: # Re-organize the directory tree to be `proton/go/pkg/...` otherwise we'll have horrid long package names. # Pick a hostname: github.com or gitbox.apache.org. It's a political decision - github is more visible, but someone should check if apache policy requires the word "apache" in the "official" package names. I'm staying out of it. # Once the decision is made it's easy - assuming we choose github and re-organize the directories as above it would be: {code:java} module github.com/qpid-proton/go/ go 1.12 {code} (I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including Fedora 30) I would do all of the above in a single release cycle and leave the qpid.apache.org redirect stuck at the current release. That way existing users won't be broken, new users use the new names. It is possible we could make the qpid.apache.org/... names continue to work, but I think it's better to make a clean break. The redirect-via-website is bewildering compared to the straightforward "package-name-equals-git-repo" convention which allows developers to easily find the source code, godocs etc. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1435) Special handling of SSL password text is not documented nor consistent with SASL
Ken Giusti created DISPATCH-1435: Summary: Special handling of SSL password text is not documented nor consistent with SASL Key: DISPATCH-1435 URL: https://issues.apache.org/jira/browse/DISPATCH-1435 Project: Qpid Dispatch Issue Type: Bug Components: Documentation, Management Agent Affects Versions: 1.9.0 Reporter: Ken Giusti The router currently checks the SSL password for the prefixes "env:" or "literal:" - see [qd_config_ssl_profile_process_password()|https://github.com/apache/qpid-dispatch/blob/master/src/connection_manager.c#L213] Two issues with this: 1) It is not documented. It needs to be documented in the qdrouter.json file as well as in the configuration section of the user guide 2) the SASL password does not provide the same feature - should it be added there as well? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942883#comment-16942883 ] ASF GitHub Bot commented on DISPATCH-1434: -- codecov-io commented on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) Report > Merging [#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc) will **increase** coverage by `<.01%`. > The diff coverage is `100%`. [![Impacted file tree graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) ```diff @@Coverage Diff @@ ## master #578 +/- ## == + Coverage 86.29% 86.29% +<.01% == Files 90 90 Lines 2038620394 +8 == + Hits1759217600 +8 Misses 2794 2794 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j) | `89.71% <100%> (+0.14%)` | :arrow_up: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.17% <0%> (-0.36%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `87.64% <0%> (-0.23%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `93.97% <0%> (-0.12%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.1% <0%> (+0.24%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `94.45% <0%> (+0.25%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `67.33% <0%> (+0.5%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer). Last update [b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) Report > Merging [#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc) will **increase** coverage by `<.01%`. > The diff coverage is `100%`. [![Impacted file tree graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) ```diff @@Coverage Diff @@ ## master #578 +/- ## == + Coverage 86.29% 86.29% +<.01% == Files 90 90 Lines 2038620394 +8 == + Hits1759217600 +8 Misses 2794 2794 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j) | `89.71% <100%> (+0.14%)` | :arrow_up: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.17% <0%> (-0.36%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `87.64% <0%> (-0.23%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `93.97% <0%> (-0.12%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.1% <0%> (+0.24%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `94.45% <0%> (+0.25%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `67.33% <0%> (+0.5%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer). Last update [b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942873#comment-16942873 ] ASF GitHub Bot commented on DISPATCH-1434: -- codecov-io commented on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) Report > Merging [#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `100%`. [![Impacted file tree graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) ```diff @@Coverage Diff @@ ## master #578 +/- ## == - Coverage 86.29% 86.28% -0.02% == Files 90 90 Lines 2038620393 +7 == + Hits1759217596 +4 - Misses 2794 2797 +3 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j) | `89.71% <100%> (+0.14%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.7% <0%> (-0.51%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `87.64% <0%> (-0.23%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.34% <0%> (-0.19%)` | :arrow_down: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `81.19% <0%> (-0.19%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `92.98% <0%> (+0.12%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `67.33% <0%> (+0.5%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer). Last update [b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) Report > Merging [#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `100%`. [![Impacted file tree graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) ```diff @@Coverage Diff @@ ## master #578 +/- ## == - Coverage 86.29% 86.28% -0.02% == Files 90 90 Lines 2038620393 +7 == + Hits1759217596 +4 - Misses 2794 2797 +3 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j) | `89.71% <100%> (+0.14%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.7% <0%> (-0.51%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `87.64% <0%> (-0.23%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.34% <0%> (-0.19%)` | :arrow_down: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `81.19% <0%> (-0.19%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `92.98% <0%> (+0.12%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `67.33% <0%> (+0.5%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer). Last update [b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942867#comment-16942867 ] ASF GitHub Bot commented on DISPATCH-1434: -- ganeshmurthy commented on pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330587020 ## File path: python/qpid_dispatch/management/qdrouter.json ## @@ -1002,10 +1002,17 @@ "saslPassword": { "type": "string", "required": false, -"description": "The password that the connector is using to connect to a peer.", +"description": "(DEPRECATED) The password that the connector is using to connect to a peer.", Review comment: Done This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330587020 ## File path: python/qpid_dispatch/management/qdrouter.json ## @@ -1002,10 +1002,17 @@ "saslPassword": { "type": "string", "required": false, -"description": "The password that the connector is using to connect to a peer.", +"description": "(DEPRECATED) The password that the connector is using to connect to a peer.", Review comment: Done This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] ncau opened a new pull request #194: ENTMQCL-1062:[CMake] Fixing an issue with cmake not compiling c++11 e…
ncau opened a new pull request #194: ENTMQCL-1062:[CMake] Fixing an issue with cmake not compiling c++11 e… URL: https://github.com/apache/qpid-proton/pull/194 On versions prior to CMake 3.0 the C++11 examples are not being compiled as the CMake code does not correctly check for c++11 compatibility. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942859#comment-16942859 ] ASF GitHub Bot commented on DISPATCH-1434: -- ganeshmurthy commented on pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330580810 ## File path: src/connection_manager.c ## @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, qd_server_config_t *conf } config->sasl_username= qd_entity_opt_string(entity, "saslUsername", 0); CHECK(); config->sasl_password= qd_entity_opt_string(entity, "saslPassword", 0); CHECK(); + +if (config->sasl_password) { +qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of entity connector has been deprecated. Use saslPasswordFile instead."); +} +else { +// saslPassword not provided. Check if saslPasswordFile property is specified. +char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 0); CHECK(); + +if (password_file) { +FILE *file = fopen(password_file, "r"); + +if (file) { +char buffer[200]; + +int c; +int i=0; + +while (i < 200 - 1) { +c = fgetc(file); +if (c == EOF || c == '\n') +break; +buffer[i++] = c; +} + +if (i != 0) { +buffer[i] = '\0'; +free(config->sasl_password); +config->sasl_password = strdup(buffer); +} +fclose(file); +} +} +free(password_file); +} + Review comment: Done This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330580810 ## File path: src/connection_manager.c ## @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, qd_server_config_t *conf } config->sasl_username= qd_entity_opt_string(entity, "saslUsername", 0); CHECK(); config->sasl_password= qd_entity_opt_string(entity, "saslPassword", 0); CHECK(); + +if (config->sasl_password) { +qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of entity connector has been deprecated. Use saslPasswordFile instead."); +} +else { +// saslPassword not provided. Check if saslPasswordFile property is specified. +char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 0); CHECK(); + +if (password_file) { +FILE *file = fopen(password_file, "r"); + +if (file) { +char buffer[200]; + +int c; +int i=0; + +while (i < 200 - 1) { +c = fgetc(file); +if (c == EOF || c == '\n') +break; +buffer[i++] = c; +} + +if (i != 0) { +buffer[i] = '\0'; +free(config->sasl_password); +config->sasl_password = strdup(buffer); +} +fclose(file); +} +} +free(password_file); +} + Review comment: Done This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942854#comment-16942854 ] ASF GitHub Bot commented on DISPATCH-1434: -- kgiusti commented on pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330577701 ## File path: python/qpid_dispatch/management/qdrouter.json ## @@ -1002,10 +1002,17 @@ "saslPassword": { "type": "string", "required": false, -"description": "The password that the connector is using to connect to a peer.", +"description": "(DEPRECATED) The password that the connector is using to connect to a peer.", Review comment: Compare this to the text description for SSL's password. SSL Password's description contains a bit more detail - can you update saslPassword's description to be consistent? > This attribute has been deprecated because it is unsafe to store plain text passwords in config files. Use the passwordFile instead This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330577701 ## File path: python/qpid_dispatch/management/qdrouter.json ## @@ -1002,10 +1002,17 @@ "saslPassword": { "type": "string", "required": false, -"description": "The password that the connector is using to connect to a peer.", +"description": "(DEPRECATED) The password that the connector is using to connect to a peer.", Review comment: Compare this to the text description for SSL's password. SSL Password's description contains a bit more detail - can you update saslPassword's description to be consistent? > This attribute has been deprecated because it is unsafe to store plain text passwords in config files. Use the passwordFile instead This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity
[ https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942813#comment-16942813 ] ASF GitHub Bot commented on DISPATCH-1434: -- kgiusti commented on pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330550035 ## File path: src/connection_manager.c ## @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, qd_server_config_t *conf } config->sasl_username= qd_entity_opt_string(entity, "saslUsername", 0); CHECK(); config->sasl_password= qd_entity_opt_string(entity, "saslPassword", 0); CHECK(); + +if (config->sasl_password) { +qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of entity connector has been deprecated. Use saslPasswordFile instead."); +} +else { +// saslPassword not provided. Check if saslPasswordFile property is specified. +char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 0); CHECK(); + +if (password_file) { +FILE *file = fopen(password_file, "r"); + +if (file) { +char buffer[200]; + +int c; +int i=0; + +while (i < 200 - 1) { +c = fgetc(file); +if (c == EOF || c == '\n') +break; +buffer[i++] = c; +} + +if (i != 0) { +buffer[i] = '\0'; +free(config->sasl_password); +config->sasl_password = strdup(buffer); +} +fclose(file); +} +} +free(password_file); +} + Review comment: This chunk of code appears to be a cut'n'paste of the ssl password file parsing. Would it be possible to eliminate the redundancy an instead create a local (static) function that does this then have both the sasl and ssl codepaths call it? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add new attribute saslPasswordFile to the connector entity > -- > > Key: DISPATCH-1434 > URL: https://issues.apache.org/jira/browse/DISPATCH-1434 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.9.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add a new attribute called saslPasswordFile to the connector entity. This > will enable users to specify the saslPassword in a file instead of specifying > it in the config file. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…
kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector… URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330550035 ## File path: src/connection_manager.c ## @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, qd_server_config_t *conf } config->sasl_username= qd_entity_opt_string(entity, "saslUsername", 0); CHECK(); config->sasl_password= qd_entity_opt_string(entity, "saslPassword", 0); CHECK(); + +if (config->sasl_password) { +qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of entity connector has been deprecated. Use saslPasswordFile instead."); +} +else { +// saslPassword not provided. Check if saslPasswordFile property is specified. +char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 0); CHECK(); + +if (password_file) { +FILE *file = fopen(password_file, "r"); + +if (file) { +char buffer[200]; + +int c; +int i=0; + +while (i < 200 - 1) { +c = fgetc(file); +if (c == EOF || c == '\n') +break; +buffer[i++] = c; +} + +if (i != 0) { +buffer[i] = '\0'; +free(config->sasl_password); +config->sasl_password = strdup(buffer); +} +fclose(file); +} +} +free(password_file); +} + Review comment: This chunk of code appears to be a cut'n'paste of the ssl password file parsing. Would it be possible to eliminate the redundancy an instead create a local (static) function that does this then have both the sasl and ssl codepaths call it? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942683#comment-16942683 ] Ulf Lilleengen commented on PROTON-2105: [~rkieley] thanks for looking at this. I'm thinking the problem with using github.com in the module URL is that this has not been the authorative module name in the past, so changing that I'm not sure is something we should do (i'm a bit confused after reading go/src/qpid.apache.org/readme-go-get.md). After your first comment, I thought how it should be is that the following file should go into the go/src/qpid.apache.org folder: {code:java} module qpid.apache.org go 1.13{code} However, I don't see a way to properly test this without actually publishing the go module, because with go modules you're not supposed to use $GOPATH to look up dependencies, but I'm not sure how one can test it locally then. Maybe [~aconway] can shed some light on how the go artifacts are published? > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8366) [Broker-J] The loss of BDB HA majority on invocation of house keeping operations can crash the broker
[ https://issues.apache.org/jira/browse/QPID-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942681#comment-16942681 ] ASF subversion and git services commented on QPID-8366: --- Commit c3d0590b7687c19958da8ef963531104f801b904 in qpid-broker-j's branch refs/heads/7.1.x from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=c3d0590 ] QPID-8366: [Broker-J] Handle ConnectionScopeRuntimeException on execution of HouseKeepingTaks (cherry picked from commit 98261ad92020c11784a3be2ab890cbabddec5fbc) > [Broker-J] The loss of BDB HA majority on invocation of house keeping > operations can crash the broker > - > > Key: QPID-8366 > URL: https://issues.apache.org/jira/browse/QPID-8366 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, > qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, > qpid-java-broker-7.1.3, qpid-java-broker-7.1.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9, > qpid-java-broker-7.1.5 > > > The {{ConnectionScopedRuntimeException}} thrown from {{VirtualHost}} {{House > Keeping}} thread on invocation of {{MessageStore}} operations like > {{checkMessageStatus}} can crash the broker. An example of such exception > stack trace (from Qpid Broker version 7.0.6) is provided below: > {noformat} > 2019-09-27 07:53:38,168 ERROR [virtualhost-test-pool-1] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number > of nodes not reachable > at > org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:495) > at > org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:332) > at > org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:288) > at > org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1090) > at > org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118) > at > org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37) > at > org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309) > at > org.apache.qpid.server.queue.QueueEntryImpl.dispose(QueueEntryImpl.java:557) > at > org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:572) > at > org.apache.qpid.server.queue.AbstractQueue$11.postCommit(AbstractQueue.java:1729) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:92) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1722) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1717) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1761) > at > org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2165) > at > org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1965) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > 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.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: com.sleepycat.je.rep.InsufficientAcksException: (JE
[jira] [Comment Edited] (QPID-8369) [Broker-J] Limit number of connections per user
[ https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942677#comment-16942677 ] Alex Rudyy edited comment on QPID-8369 at 10/2/19 10:10 AM: The suggested limits (number of connections per user and maximum frequency of connections per user) can be implemented as settings in ACL rules. We already have {{VirtualHost}} access rule which can be expressed like below: {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST {noformat} Potentially, the rule can be expanded to something like below {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 connection_frequency_limit=60 {noformat} The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit the number of connections allowed to create by "guest" to {{10}} . Whilst the {{connection_frequency_limit}} would limit the maximum frequency of connection creation for "guest" to {{60}}. Essentially, any user or a group of users could be limited in such way. Absence of {{connection_limit}} and {{connection_frequency_limit}} settings would indicate about unlimited access. Providing such settings in {{DENY}} rule does not looks to me as having much sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits. What do you think about such approach? Obviously, the rule will limit only AMQP connections. If malicious user would try to perform DOS attack, the rule would be applied on finishing of authentication stage. Thus, before the authentication any number of TCP connections can be created. I am wondering whether a similar limits can be applied to IP or domain addresses in order to restrict the number of TCP connections which can be open from given host or domain address. Thus, if IP/domain address check is performed immediately after opening of TCP connection, it would eliminate the need to wait for applying the limit for connection principal, if IP/domain address limit is breached. Thus, such breaching connection would be closed immediately and might save some host resources. I am not sure whether adding such check make sense. Perhaps, it should be a responsibility of some proxy/gateway sitting in front of the broker instance. What do you think? was (Author: alex.rufous): The suggested limits (number of connections per user and maximum frequency of connections per user) can be implemented as settings in ACL rules. We already have {{VirtualHost}} access rule which can be expressed like below: {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST {noformat} Potentially, the rule can be expanded to something like below {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 connection_frequency_limit=60 {noformat} The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit the number of connections allowed to create by "guest" to {{10}} . Whilst the {{connection_frequency_limit}} would limit the maximum frequency of connection creation for "guest" to {{60}}. Essentially, any user or a group of users could be limited in such way. Absence of {{connection_limit}} and {{connection_frequency_limit}} settings would incicate about unlimited access. Providing such settings in {{DENY}} rule does not looks to me as having much sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits. What do you think about such approach? Obviously, the rule will limit only AMQP connections. If malicious user would try to perform DOS attack, the rule would be applied on finishing of authentication stage. Thus, before the authentication any number of TCP connections can be created. I am wondering whether a similar limits can be applied to IP or domain addresses in order to restrict the number of TCP connections which can be open from given host or domain address. Thus, if IP/domain address check is performed immediately after opening of TCP connection, it would eliminate the need to wait for applying the limit for connection principal, if IP/domain address limit is breached. Thus, such breaching connection would be closed immediately and might save some host resources. I am not sure whether adding such check make sense. Perhaps, it should be a responsibility of some proxy/gateway sitting in front of the broker instance. What do you think? > [Broker-J] Limit number of connections per user > --- > > Key: QPID-8369 > URL: https://issues.apache.org/jira/browse/QPID-8369 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Tomas Vavricka >Priority: Major > Labels: connection, limit, user > Fix For: qpid-java-broker-8.0.0 > > > There is only limit for number of connections per amqp/amqps port. > If some user creates too much connections, he can
[jira] [Comment Edited] (QPID-8369) [Broker-J] Limit number of connections per user
[ https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942677#comment-16942677 ] Alex Rudyy edited comment on QPID-8369 at 10/2/19 10:08 AM: The suggested limits (number of connections per user and maximum frequency of connections per user) can be implemented as settings in ACL rules. We already have {{VirtualHost}} access rule which can be expressed like below: {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST {noformat} Potentially, the rule can be expanded to something like below {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 connection_frequency_limit=60 {noformat} The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit the number of connections allowed to create by "guest" to {{10}} . Whilst the {{connection_frequency_limit}} would limit the maximum frequency of connection creation for "guest" to {{60}}. Essentially, any user or a group of users could be limited in such way. Absence of {{connection_limit}} and {{connection_frequency_limit}} settings would incicate about unlimited access. Providing such settings in {{DENY}} rule does not looks to me as having much sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits. What do you think about such approach? Obviously, the rule will limit only AMQP connections. If malicious user would try to perform DOS attack, the rule would be applied on finishing of authentication stage. Thus, before the authentication any number of TCP connections can be created. I am wondering whether a similar limits can be applied to IP or domain addresses in order to restrict the number of TCP connections which can be open from given host or domain address. Thus, if IP/domain address check is performed immediately after opening of TCP connection, it would eliminate the need to wait for applying the limit for connection principal, if IP/domain address limit is breached. Thus, such breaching connection would be closed immediately and might save some host resources. I am not sure whether adding such check make sense. Perhaps, it should be a responsibility of some proxy/gateway sitting in front of the broker instance. What do you think? was (Author: alex.rufous): The suggested limits (number of connections per user and maximum frequency of connections per user) can be implemented as settings in ACL rules. We already have {{VirtualHost}} access rule which can be expressed like below: {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST {noformat} Potentially, the rule can be expanded to something like below {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 connection_frequency_limit=60 {noformat} The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit the number of connections allowed to create by "guest" to {{10}} . Whilst the and {{connection_frequency_limit}} would limit the maximum frequency of connection creation for "guest" to {{60}}. Essentially, any user or a group of users could be limited in such way. Absence of {{connection_limit}} and {{connection_frequency_limit}} settings would incicate about unlimited access. Providing such settings in {{DENY}} rule does not looks to me as having much sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits. What do you think about such approach? Obviously, the rule will limit only AMQP connections. If malicious user would try to perform DOS attack, the rule would be applied on finishing of authentication stage. Thus, before the authentication any number of TCP connections can be created. I am wondering whether a similar limits can be applied to IP or domain addresses in order to restrict the number of TCP connections which can be open from given host or domain address. Thus, if IP/domain address check is performed immediately after opening of TCP connection, it would eliminate the need to wait for applying the limit for connection principal, if IP/domain address limit is breached. Thus, such breaching connection would be closed immediately and might save some host resources. I am not sure whether adding such check make sense. Perhaps, it should be a responsibility of some proxy/gateway sitting in front of the broker instance. What do you think? > [Broker-J] Limit number of connections per user > --- > > Key: QPID-8369 > URL: https://issues.apache.org/jira/browse/QPID-8369 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Tomas Vavricka >Priority: Major > Labels: connection, limit, user > Fix For: qpid-java-broker-8.0.0 > > > There is only limit for number of connections per amqp/amqps port. > If some user creates too much connections, he can
[jira] [Commented] (QPID-8369) [Broker-J] Limit number of connections per user
[ https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942677#comment-16942677 ] Alex Rudyy commented on QPID-8369: -- The suggested limits (number of connections per user and maximum frequency of connections per user) can be implemented as settings in ACL rules. We already have {{VirtualHost}} access rule which can be expressed like below: {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST {noformat} Potentially, the rule can be expanded to something like below {noformat} ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 connection_frequency_limit=60 {noformat} The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit the number of connections allowed to create by "guest" to {{10}} . Whilst the and {{connection_frequency_limit}} would limit the maximum frequency of connection creation for "guest" to {{60}}. Essentially, any user or a group of users could be limited in such way. Absence of {{connection_limit}} and {{connection_frequency_limit}} settings would incicate about unlimited access. Providing such settings in {{DENY}} rule does not looks to me as having much sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits. What do you think about such approach? Obviously, the rule will limit only AMQP connections. If malicious user would try to perform DOS attack, the rule would be applied on finishing of authentication stage. Thus, before the authentication any number of TCP connections can be created. I am wondering whether a similar limits can be applied to IP or domain addresses in order to restrict the number of TCP connections which can be open from given host or domain address. Thus, if IP/domain address check is performed immediately after opening of TCP connection, it would eliminate the need to wait for applying the limit for connection principal, if IP/domain address limit is breached. Thus, such breaching connection would be closed immediately and might save some host resources. I am not sure whether adding such check make sense. Perhaps, it should be a responsibility of some proxy/gateway sitting in front of the broker instance. What do you think? > [Broker-J] Limit number of connections per user > --- > > Key: QPID-8369 > URL: https://issues.apache.org/jira/browse/QPID-8369 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Tomas Vavricka >Priority: Major > Labels: connection, limit, user > Fix For: qpid-java-broker-8.0.0 > > > There is only limit for number of connections per amqp/amqps port. > If some user creates too much connections, he can prevent other users from > connecting to amqp ports. > Qpid Broker-J should support some limitation for connections per user. > Broker should also support limitation of number of created connections per > time frame ex: create 60 connections per one minute at maximum -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8366) [Broker-J] The loss of BDB HA majority on invocation of house keeping operations can crash the broker
[ https://issues.apache.org/jira/browse/QPID-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8366: - Status: Reviewable (was: In Progress) > [Broker-J] The loss of BDB HA majority on invocation of house keeping > operations can crash the broker > - > > Key: QPID-8366 > URL: https://issues.apache.org/jira/browse/QPID-8366 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, > qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, > qpid-java-broker-7.1.3, qpid-java-broker-7.1.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9, > qpid-java-broker-7.1.5 > > > The {{ConnectionScopedRuntimeException}} thrown from {{VirtualHost}} {{House > Keeping}} thread on invocation of {{MessageStore}} operations like > {{checkMessageStatus}} can crash the broker. An example of such exception > stack trace (from Qpid Broker version 7.0.6) is provided below: > {noformat} > 2019-09-27 07:53:38,168 ERROR [virtualhost-test-pool-1] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number > of nodes not reachable > at > org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:495) > at > org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:332) > at > org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:288) > at > org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1090) > at > org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118) > at > org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37) > at > org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309) > at > org.apache.qpid.server.queue.QueueEntryImpl.dispose(QueueEntryImpl.java:557) > at > org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:572) > at > org.apache.qpid.server.queue.AbstractQueue$11.postCommit(AbstractQueue.java:1729) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:92) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1722) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1717) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1761) > at > org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2165) > at > org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1965) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > 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.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: com.sleepycat.je.rep.InsufficientAcksException: (JE 7.4.5) > Transaction: -3459038252 VLSN: 10,380,435,448, initiated at: 07:53:20. > Insufficient acks for policy:SIMPLE_MAJORITY. Need replica acks: 2. Missing > replica acks: 2. Timeout: 15000ms. FeederState=acc3_2(3)[MASTER] > Current feeds: > acc3_1: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396 > acc3: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396 >
[jira] [Assigned] (QPID-8366) [Broker-J] The loss of BDB HA majority on invocation of house keeping operations can crash the broker
[ https://issues.apache.org/jira/browse/QPID-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8366: Assignee: Alex Rudyy > [Broker-J] The loss of BDB HA majority on invocation of house keeping > operations can crash the broker > - > > Key: QPID-8366 > URL: https://issues.apache.org/jira/browse/QPID-8366 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, > qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, > qpid-java-broker-7.1.3, qpid-java-broker-7.1.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9, > qpid-java-broker-7.1.5 > > > The {{ConnectionScopedRuntimeException}} thrown from {{VirtualHost}} {{House > Keeping}} thread on invocation of {{MessageStore}} operations like > {{checkMessageStatus}} can crash the broker. An example of such exception > stack trace (from Qpid Broker version 7.0.6) is provided below: > {noformat} > 2019-09-27 07:53:38,168 ERROR [virtualhost-test-pool-1] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number > of nodes not reachable > at > org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:495) > at > org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:332) > at > org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:288) > at > org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1090) > at > org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118) > at > org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37) > at > org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309) > at > org.apache.qpid.server.queue.QueueEntryImpl.dispose(QueueEntryImpl.java:557) > at > org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:572) > at > org.apache.qpid.server.queue.AbstractQueue$11.postCommit(AbstractQueue.java:1729) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:92) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1722) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1717) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1761) > at > org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2165) > at > org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1965) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > 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.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: com.sleepycat.je.rep.InsufficientAcksException: (JE 7.4.5) > Transaction: -3459038252 VLSN: 10,380,435,448, initiated at: 07:53:20. > Insufficient acks for policy:SIMPLE_MAJORITY. Need replica acks: 2. Missing > replica acks: 2. Timeout: 15000ms. FeederState=acc3_2(3)[MASTER] > Current feeds: > acc3_1: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396 > acc3: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396 > at
[jira] [Created] (QPID-8370) [Broker-J] Option to disable WebGUI
Tomas Vavricka created QPID-8370: Summary: [Broker-J] Option to disable WebGUI Key: QPID-8370 URL: https://issues.apache.org/jira/browse/QPID-8370 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Tomas Vavricka Fix For: qpid-java-broker-8.0.0 Qpid Broker-J should support disabling of WebGui by configuration parameter. Broker REST API should be enabled even if broker's WebGui is disabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8369) [Broker-J] Limit number of connections per user
Tomas Vavricka created QPID-8369: Summary: [Broker-J] Limit number of connections per user Key: QPID-8369 URL: https://issues.apache.org/jira/browse/QPID-8369 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Tomas Vavricka Fix For: qpid-java-broker-8.0.0 There is only limit for number of connections per amqp/amqps port. If some user creates too much connections, he can prevent other users from connecting to amqp ports. Qpid Broker-J should support some limitation for connections per user. Broker should also support limitation of number of created connections per time frame ex: create 60 connections per one minute at maximum -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8368) [Broker-J] Graylog support
[ https://issues.apache.org/jira/browse/QPID-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vavricka updated QPID-8368: - Fix Version/s: (was: Future) qpid-java-broker-8.0.0 > [Broker-J] Graylog support > -- > > Key: QPID-8368 > URL: https://issues.apache.org/jira/browse/QPID-8368 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Tomas Vavricka >Priority: Major > Labels: logging > Fix For: qpid-java-broker-8.0.0 > > > Graylog is widely used logging service based on ElasticSearch. Qpid Broker-J > should support Graylog as one of Broker Loggers type. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8367) [Broker-J] Trusted CA revocation list
[ https://issues.apache.org/jira/browse/QPID-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vavricka updated QPID-8367: - Fix Version/s: (was: Future) qpid-java-broker-8.0.0 > [Broker-J] Trusted CA revocation list > - > > Key: QPID-8367 > URL: https://issues.apache.org/jira/browse/QPID-8367 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Tomas Vavricka >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > Qpid Broker-J supports custom CA. When in place clients then can connect with > certificate signed by custom CA. > However there is no way to reject compromised certificates. Implementation of > revocation list for custom CA can solve this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8368) [Broker-J] Graylog support
Tomas Vavricka created QPID-8368: Summary: [Broker-J] Graylog support Key: QPID-8368 URL: https://issues.apache.org/jira/browse/QPID-8368 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Tomas Vavricka Fix For: Future Graylog is widely used logging service based on ElasticSearch. Qpid Broker-J should support Graylog as one of Broker Loggers type. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8367) [Broker-J] Trusted CA revocation list
Tomas Vavricka created QPID-8367: Summary: [Broker-J] Trusted CA revocation list Key: QPID-8367 URL: https://issues.apache.org/jira/browse/QPID-8367 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Tomas Vavricka Fix For: Future Qpid Broker-J supports custom CA. When in place clients then can connect with certificate signed by custom CA. However there is no way to reject compromised certificates. Implementation of revocation list for custom CA can solve this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org