[GitHub] qpid-dispatch pull request #241: DISPATCH-906 Create procedure for integrati...
Github user enkeys commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/241#discussion_r161148398
--- Diff: doc/new-book/configuration-security.adoc ---
@@ -373,22 +373,26 @@ This is the service principal that {RouterName} uses.
.Procedure
. On the router's host machine, open the `/etc/sasl2/qdrouterd.conf`
configuration file.
-
-. Verify that the `mech_list` attribute contains the `GSSAPI` mechanism.
+
--
-.The `/etc/sasl2/qdrouterd.conf` Configuration File
+.An `/etc/sasl2/qdrouterd.conf` Configuration File
[options="nowrap"]
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: qdrouterd.sasldb
+keytab: /tmp/keytabs/server.keytab
--- End diff --
:+1: true @jdanekrh
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-906) Document Kerberos integration
[
https://issues.apache.org/jira/browse/DISPATCH-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323610#comment-16323610
]
ASF GitHub Bot commented on DISPATCH-906:
-
Github user enkeys commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/241#discussion_r161148398
--- Diff: doc/new-book/configuration-security.adoc ---
@@ -373,22 +373,26 @@ This is the service principal that {RouterName} uses.
.Procedure
. On the router's host machine, open the `/etc/sasl2/qdrouterd.conf`
configuration file.
-
-. Verify that the `mech_list` attribute contains the `GSSAPI` mechanism.
+
--
-.The `/etc/sasl2/qdrouterd.conf` Configuration File
+.An `/etc/sasl2/qdrouterd.conf` Configuration File
[options="nowrap"]
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: qdrouterd.sasldb
+keytab: /tmp/keytabs/server.keytab
--- End diff --
:+1: true @jdanekrh
> Document Kerberos integration
> -
>
> Key: DISPATCH-906
> URL: https://issues.apache.org/jira/browse/DISPATCH-906
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Document requirements and for accepting Kerberos authenticated connections.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #135: PROTON-1732: [OSX] Enable swig for the Travis CI bui...
Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/135 But failing that I'm happy with what's there now. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1732) [OSX] Enable swig for the Travis CI build
[ https://issues.apache.org/jira/browse/PROTON-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323464#comment-16323464 ] ASF GitHub Bot commented on PROTON-1732: Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/135 But failing that I'm happy with what's there now. > [OSX] Enable swig for the Travis CI build > - > > Key: PROTON-1732 > URL: https://issues.apache.org/jira/browse/PROTON-1732 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c >Affects Versions: proton-c-0.19.0 > Environment: Travis CI > Xcode 7.3, 9 >Reporter: Roddie Kieley >Priority: Minor > Fix For: proton-c-future > > > Comparing the current travis builds for linux and osx we see that the linux > builds cover ruby whereas the osx builds do not. Swig is required for this to > occur. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1732) [OSX] Enable swig for the Travis CI build
[ https://issues.apache.org/jira/browse/PROTON-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323463#comment-16323463 ] ASF GitHub Bot commented on PROTON-1732: Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/135 Maybe I'm the one who misunderstands how env and matrix interact then. Only one other thing I might suggest is to just use pip2 everywhere without a variable at all - It looks like that should work on Ubuntu and will avoid bringing attention to this irrelevant detail. > [OSX] Enable swig for the Travis CI build > - > > Key: PROTON-1732 > URL: https://issues.apache.org/jira/browse/PROTON-1732 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c >Affects Versions: proton-c-0.19.0 > Environment: Travis CI > Xcode 7.3, 9 >Reporter: Roddie Kieley >Priority: Minor > Fix For: proton-c-future > > > Comparing the current travis builds for linux and osx we see that the linux > builds cover ruby whereas the osx builds do not. Swig is required for this to > occur. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #135: PROTON-1732: [OSX] Enable swig for the Travis CI bui...
Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/135 Maybe I'm the one who misunderstands how env and matrix interact then. Only one other thing I might suggest is to just use pip2 everywhere without a variable at all - It looks like that should work on Ubuntu and will avoid bringing attention to this irrelevant detail. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1732) [OSX] Enable swig for the Travis CI build
[ https://issues.apache.org/jira/browse/PROTON-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323428#comment-16323428 ] ASF GitHub Bot commented on PROTON-1732: Github user RoddieKieley commented on the issue: https://github.com/apache/qpid-proton/pull/135 No luck with having the global PIP env var utilized by the linux os matrix [build](https://travis-ci.org/RoddieKieley/qpid-proton/jobs/327947850). Was there something I missed? > [OSX] Enable swig for the Travis CI build > - > > Key: PROTON-1732 > URL: https://issues.apache.org/jira/browse/PROTON-1732 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c >Affects Versions: proton-c-0.19.0 > Environment: Travis CI > Xcode 7.3, 9 >Reporter: Roddie Kieley >Priority: Minor > Fix For: proton-c-future > > > Comparing the current travis builds for linux and osx we see that the linux > builds cover ruby whereas the osx builds do not. Swig is required for this to > occur. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #135: PROTON-1732: [OSX] Enable swig for the Travis CI bui...
Github user RoddieKieley commented on the issue: https://github.com/apache/qpid-proton/pull/135 No luck with having the global PIP env var utilized by the linux os matrix [build](https://travis-ci.org/RoddieKieley/qpid-proton/jobs/327947850). Was there something I missed? --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323111#comment-16323111
]
ASF subversion and git services commented on QPID-8074:
---
Commit 8fdc97492de3b6ee9f9247687e9c876f3803bf43 in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=8fdc974 ]
QPID-8074: [JMS AMQP 0-x][System Tests] Add cpp broker profile
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323112#comment-16323112
]
ASF subversion and git services commented on QPID-8074:
---
Commit 43d155b1c14d08b19a5f1381079ec9cb6771e6a4 in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=43d155b ]
QPID-8074: [JMS AMQP 0-x][System Tests] Reduce amount of Broker-J logs between
tests
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-906) Document Kerberos integration
[
https://issues.apache.org/jira/browse/DISPATCH-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323057#comment-16323057
]
ASF GitHub Bot commented on DISPATCH-906:
-
Github user jdanekrh commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/241#discussion_r161090032
--- Diff: doc/new-book/configuration-security.adoc ---
@@ -373,22 +373,26 @@ This is the service principal that {RouterName} uses.
.Procedure
. On the router's host machine, open the `/etc/sasl2/qdrouterd.conf`
configuration file.
-
-. Verify that the `mech_list` attribute contains the `GSSAPI` mechanism.
+
--
-.The `/etc/sasl2/qdrouterd.conf` Configuration File
+.An `/etc/sasl2/qdrouterd.conf` Configuration File
[options="nowrap"]
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: qdrouterd.sasldb
+keytab: /tmp/keytabs/server.keytab
--- End diff --
Probably not `/tmp/`, though. That would be silly thing to do in actual
deployment for the fact that RHELs auto-delete old files under `/tmp`. There
are AFAIK supposed to be permissions related security issues around using /tmp,
but I am now unable to find more on this.
> Document Kerberos integration
> -
>
> Key: DISPATCH-906
> URL: https://issues.apache.org/jira/browse/DISPATCH-906
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Document requirements and for accepting Kerberos authenticated connections.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #241: DISPATCH-906 Create procedure for integrati...
Github user jdanekrh commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/241#discussion_r161090032
--- Diff: doc/new-book/configuration-security.adoc ---
@@ -373,22 +373,26 @@ This is the service principal that {RouterName} uses.
.Procedure
. On the router's host machine, open the `/etc/sasl2/qdrouterd.conf`
configuration file.
-
-. Verify that the `mech_list` attribute contains the `GSSAPI` mechanism.
+
--
-.The `/etc/sasl2/qdrouterd.conf` Configuration File
+.An `/etc/sasl2/qdrouterd.conf` Configuration File
[options="nowrap"]
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: qdrouterd.sasldb
+keytab: /tmp/keytabs/server.keytab
--- End diff --
Probably not `/tmp/`, though. That would be silly thing to do in actual
deployment for the fact that RHELs auto-delete old files under `/tmp`. There
are AFAIK supposed to be permissions related security issues around using /tmp,
but I am now unable to find more on this.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.
[ https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323039#comment-16323039 ] Ben Hardesty commented on DISPATCH-333: --- The Policy chapter already exists, so I'll use this JIRA to update and enhance that content. > Add a chapter on policy to the Qpid Dispatch Router Book. > - > > Key: DISPATCH-333 > URL: https://issues.apache.org/jira/browse/DISPATCH-333 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy >Assignee: Ben Hardesty >Priority: Minor > > Add a new chapter containing details on how policy works and how to setup > policy to the Qpid Dispatch Router Book -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.
[ https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Hardesty reassigned DISPATCH-333: - Assignee: Ben Hardesty (was: Chuck Rolke) > Add a chapter on policy to the Qpid Dispatch Router Book. > - > > Key: DISPATCH-333 > URL: https://issues.apache.org/jira/browse/DISPATCH-333 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy >Assignee: Ben Hardesty >Priority: Minor > > Add a new chapter containing details on how policy works and how to setup > policy to the Qpid Dispatch Router Book -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-906) Document Kerberos integration
[ https://issues.apache.org/jira/browse/DISPATCH-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322949#comment-16322949 ] ASF GitHub Bot commented on DISPATCH-906: - Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/241 @enkeys I added a bit about the keytab attribute. I don't think we need to say anything about KRB5_CONFIG since it's specific to the Kerberos implementation (which is out of scope for Dispatch Router). AFAIK, you only need to set that environment variable if you put krb5.conf in a non-default directory (which would be part of the Kerberos configuration/implementation, not Dispatch Router configuration). > Document Kerberos integration > - > > Key: DISPATCH-906 > URL: https://issues.apache.org/jira/browse/DISPATCH-906 > Project: Qpid Dispatch > Issue Type: Bug > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty > > Document requirements and for accepting Kerberos authenticated connections. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #241: DISPATCH-906 Create procedure for integrating disp...
Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/241 @enkeys I added a bit about the keytab attribute. I don't think we need to say anything about KRB5_CONFIG since it's specific to the Kerberos implementation (which is out of scope for Dispatch Router). AFAIK, you only need to set that environment variable if you put krb5.conf in a non-default directory (which would be part of the Kerberos configuration/implementation, not Dispatch Router configuration). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322641#comment-16322641 ] ASF subversion and git services commented on QPID-6933: --- Commit ccf691b2caeb16e2f9421146cfefd3489a6bf5bf in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ccf691b ] QPID-6933: [System Tests] Refactor PersistentStoreTest as JMS 1.1 system test > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[
https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322640#comment-16322640
]
ASF subversion and git services commented on QPID-8017:
---
Commit 835efa54b82d9780d4f59a2363919d302b68a10d in qpid-broker-j's branch
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=835efa5 ]
QPID-8017: [Broker-J] [BDB] Add context variable that allows the JUL logging
level of JUL loggers to be overridden.
> [Broker-J] [BDB] JE log events written at JUL level FINE and below not
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8017-Broker-J-Propagate-logger-rules-into-JUL-l.patch
>
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour: verbose logging from JE. Actual behaviour: moderate
> logging only
> For instance, JE writes the following message at {{FINE}} which should be
> logged by the handler as {{TRACE}} but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) -
> [default] Clean file none: predicted min util is below minUtilization,
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the functional problem, albeit a restart is
> required and the ability to change the process's system properties. Use the
> normal JUL system property {{java.util.logging.config.file}}. Set this to
> the location of a logging.properties file with the {{com.sleepycat.je}}
> logger set to the desired level. Once the JVM is restarted, the Broker's log
> files will include the logging.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322639#comment-16322639 ] ASF subversion and git services commented on QPID-6933: --- Commit 8312b9ffacf642f5cb83ce4edf56c91ea2e42de3 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8312b9f ] QPID-6933: [System Tests] Remove ModelTest - tested the ability to explicitly declare durable/exclusive queues using Qpid specific extension to the JMS API. Server side concerns now covered by 0-9/0-10 protocol tests. > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1690) JMH Benchmarks for baseline performance of encoding/decoding
[ https://issues.apache.org/jira/browse/PROTON-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322564#comment-16322564 ] ASF subversion and git services commented on PROTON-1690: - Commit bb23a5c2903c5c0da730db3c49584b998ecc4662 in qpid-proton-j's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=bb23a5c ] add configuration toggle to enable some release-time checks, missed from PROTON-1690 > JMH Benchmarks for baseline performance of encoding/decoding > > > Key: PROTON-1690 > URL: https://issues.apache.org/jira/browse/PROTON-1690 > Project: Qpid Proton > Issue Type: Task > Components: proton-j >Reporter: Francesco Nigro >Assignee: Robbie Gemmell >Priority: Minor > Fix For: proton-j-0.24.0 > > > Using a standard and reliable tool to quantify the performances of critical > components would be useful to measure the effects of any changes in the > engine. > Currently lo standard the facto for such measurements is JMH > (http://openjdk.java.net/projects/code-tools/jmh/) hence it is highly > desiderable to use it to avoid the JVM to perform un-wanted (ie unrealistic > in production uses) optimizations that could trick the results of any > handrolled measurements. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322554#comment-16322554
]
Timothy Bish commented on QPIDJMS-353:
--
There aren't any plans to implement a Qpid JMS specific pooled connection
factory. There are already a few generic options that should work so there
isn't really a need to invent a new one.
One option is to use the PooledConnectionFactory provided by ActiveMQ which is
a JMS 1.1 based Connection pooling utility. It is tested with Camel already as
it is used to pool the ActiveMQ Connections. You can find the docs
[here|https://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html],
and the maven artifacts are
[here|https://mvnrepository.com/artifact/org.apache.activemq/activemq-pool/5.15.2].
Another option is [this|https://github.com/messaginghub/pooled-jms] JMS 2.0
aware Connection pool which you can use via the maven artifacts
[here|https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22pooled-jms%22].
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322554#comment-16322554
]
Timothy Bish edited comment on QPIDJMS-353 at 1/11/18 4:58 PM:
---
There aren't any plans to implement a Qpid JMS specific pooled connection
factory. There are already a few generic options that should work so there
isn't really a need to invent a new one.
One option is to use the PooledConnectionFactory provided by ActiveMQ which is
a JMS 1.1 based Connection pooling utility. It is tested with Camel already as
it is used to pool the ActiveMQ Connections. You can find the docs
[here|https://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html],
and the maven artifacts are
[here|https://mvnrepository.com/artifact/org.apache.activemq/activemq-pool/5.15.2].
Another option is [this|https://github.com/messaginghub/pooled-jms] JMS 2.0
aware Connection pool which you can use via the maven artifacts
[here|https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22pooled-jms%22]. This
project has tests that use the Qpid JMS client library which you can use as a
reference for configuring it.
was (Author: tabish121):
There aren't any plans to implement a Qpid JMS specific pooled connection
factory. There are already a few generic options that should work so there
isn't really a need to invent a new one.
One option is to use the PooledConnectionFactory provided by ActiveMQ which is
a JMS 1.1 based Connection pooling utility. It is tested with Camel already as
it is used to pool the ActiveMQ Connections. You can find the docs
[here|https://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html],
and the maven artifacts are
[here|https://mvnrepository.com/artifact/org.apache.activemq/activemq-pool/5.15.2].
Another option is [this|https://github.com/messaginghub/pooled-jms] JMS 2.0
aware Connection pool which you can use via the maven artifacts
[here|https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22pooled-jms%22].
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1728) [proton-c] Reorganize the source tree now that Proton J is split off
[ https://issues.apache.org/jira/browse/PROTON-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322445#comment-16322445 ] ASF GitHub Bot commented on PROTON-1728: Github user ssorj commented on the issue: https://github.com/apache/qpid-proton/pull/132 One more change I'd like to consider making is moving the language-specific examples with their binding code. That's consistent with how we currently handle docs, and it will make the cmake logic a bit more natural. > [proton-c] Reorganize the source tree now that Proton J is split off > > > Key: PROTON-1728 > URL: https://issues.apache.org/jira/browse/PROTON-1728 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1739) remove confusing default for session capacity and allow disabling it
[ https://issues.apache.org/jira/browse/PROTON-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1739: --- Priority: Minor (was: Major) > remove confusing default for session capacity and allow disabling it > > > Key: PROTON-1739 > URL: https://issues.apache.org/jira/browse/PROTON-1739 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: proton-j-0.25.0 > > > The session has a default 'incoming capacity' of 1MB, which actually has no > effect by default and leads to unexpected behaviour while changing other > configuration. It should be removed. > The value is used when the engine decides what incoming session window to set > on Flow frames, but only if a specific frame size is configured for the > transport, which it isn't by default. If a specific frame size is set, then > any session capacity really needs to be set based on it in order to be > appropriate, the default being fixed as it is leads to unexpectedly low > window sizes in many cases which will impact performance in unexpected ways. > Its confusing that setting frame size results in completely different > behaviour than before for another thing (window size) which perhaps hasn't > been configured at all, and the existing behaviour is also such that you cant > turn it off. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1739) remove confusing default for session capacity and allow disabling it
[ https://issues.apache.org/jira/browse/PROTON-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-1739. Resolution: Fixed > remove confusing default for session capacity and allow disabling it > > > Key: PROTON-1739 > URL: https://issues.apache.org/jira/browse/PROTON-1739 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-j-0.25.0 > > > The session has a default 'incoming capacity' of 1MB, which actually has no > effect by default and leads to unexpected behaviour while changing other > configuration. It should be removed. > The value is used when the engine decides what incoming session window to set > on Flow frames, but only if a specific frame size is configured for the > transport, which it isn't by default. If a specific frame size is set, then > any session capacity really needs to be set based on it in order to be > appropriate, the default being fixed as it is leads to unexpectedly low > window sizes in many cases which will impact performance in unexpected ways. > Its confusing that setting frame size results in completely different > behaviour than before for another thing (window size) which perhaps hasn't > been configured at all, and the existing behaviour is also such that you cant > turn it off. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #132: PROTON-1728: WIP: Reorganize the source tree and rem...
Github user ssorj commented on the issue: https://github.com/apache/qpid-proton/pull/132 One more change I'd like to consider making is moving the language-specific examples with their binding code. That's consistent with how we currently handle docs, and it will make the cmake logic a bit more natural. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322430#comment-16322430
]
ASF subversion and git services commented on QPID-8074:
---
Commit a21316270ba311e75859bf874464e32fc1c0f351 in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=a213162 ]
QPID-8074: [JMS AMQP 0-x][System Tests] Segregate broker test logs with client
test logs in the same log file
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322428#comment-16322428
]
ASF subversion and git services commented on QPID-8074:
---
Commit 9374adf037a790dab9e6beef50e3842c434fe551 in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=9374adf ]
QPID-8074: [JMS AMQP 0-x][System Tests] Copy client specofic test
ConnectionTest from Broker-J sources
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322429#comment-16322429
]
ASF subversion and git services commented on QPID-8074:
---
Commit 450005bf555c51e688e5c046f4a9684017a73a55 in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=450005b ]
QPID-8074: [JMS AMQP 0-x][System Tests] Run system tests as part of
integration-test maven phase
* Change surefire settings to run system tests as part of integration-test
maven phase
* Change surefire settings to have separate working directories per amqp
protocol
* Describe how to run system tests in README.txt
* Fix typos
* Miscellaneous minor improvements
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1739) remove confusing default for session capacity and allow disabling it
[ https://issues.apache.org/jira/browse/PROTON-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322418#comment-16322418 ] ASF subversion and git services commented on PROTON-1739: - Commit d9eea74658329d65fb8aec1a21f2daf979b1f83e in qpid-proton-j's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=d9eea74 ] PROTON-1739: add a test to ensure the behaviour > remove confusing default for session capacity and allow disabling it > > > Key: PROTON-1739 > URL: https://issues.apache.org/jira/browse/PROTON-1739 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-j-0.25.0 > > > The session has a default 'incoming capacity' of 1MB, which actually has no > effect by default and leads to unexpected behaviour while changing other > configuration. It should be removed. > The value is used when the engine decides what incoming session window to set > on Flow frames, but only if a specific frame size is configured for the > transport, which it isn't by default. If a specific frame size is set, then > any session capacity really needs to be set based on it in order to be > appropriate, the default being fixed as it is leads to unexpectedly low > window sizes in many cases which will impact performance in unexpected ways. > Its confusing that setting frame size results in completely different > behaviour than before for another thing (window size) which perhaps hasn't > been configured at all, and the existing behaviour is also such that you cant > turn it off. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[
https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322309#comment-16322309
]
Keith Wall commented on QPID-8017:
--
In the end I opted for a simple context variable that forces the BDB module to
override the level applied to zero or more JUL loggers. This can be used to
raise the logging level one one or more JE loggers (say "com.sleepycat.je", or
"com.sleepycat.je.cleaner.Cleaner" so that their logging hits the
{{Slf4jLoggingHandler}} and is then subjected to Broker-J's normal rules
(inclusion rules etc). After setting the context variable it is necessary to
restart the the BDB VH and VHNs so that the configuration is picked-up.
Removing the context variable won't revert the JUL loggers back to their
original state - a JVM restart is the only sure way. I did look at several
alternative mechanisms, but all ended up bring too many complications and what
is a small benefit. I think this should be good enough for a user wishing to
debug Broker-J precise interaction with JE.
Separately, I noticed the the JE logs sent to a virtualhost logger will always
be incomplete. This is because JE's threads do not carry the virtualhost
principal so are not eligible to be logged. If you wish to see a complete JE
trace, we must log at the Broker level to see the complete story.
> [Broker-J] [BDB] JE log events written at JUL level FINE and below not
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8017-Broker-J-Propagate-logger-rules-into-JUL-l.patch
>
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour: verbose logging from JE. Actual behaviour: moderate
> logging only
> For instance, JE writes the following message at {{FINE}} which should be
> logged by the handler as {{TRACE}} but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) -
> [default] Clean file none: predicted min util is below minUtilization,
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the functional problem, albeit a restart is
> required and the ability to change the process's system properties. Use the
> normal JUL system property {{java.util.logging.config.file}}. Set this to
> the location of a logging.properties file with the {{com.sleepycat.je}}
> logger set to the desired level. Once the JVM is restarted, the Broker's log
> files will include the logging.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1728) [proton-c] Reorganize the source tree now that Proton J is split off
[ https://issues.apache.org/jira/browse/PROTON-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322276#comment-16322276 ] ASF GitHub Bot commented on PROTON-1728: Github user ChugR commented on the issue: https://github.com/apache/qpid-proton/pull/132 * This seems like a great improvement overall. It's easier to find stuff without needing the folklore to locate it. * The presentation of the source tree gives the project a mature look and feel. * Compiled on windows VS2012 x64 and ran tests OK. A few observations: * Why is there a directory src/extra? This seems odd after such a massive cleanup. * As a downstream consumer of the binary artifacts the minor reorganization is acceptable. > [proton-c] Reorganize the source tree now that Proton J is split off > > > Key: PROTON-1728 > URL: https://issues.apache.org/jira/browse/PROTON-1728 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #132: PROTON-1728: WIP: Reorganize the source tree and rem...
Github user ChugR commented on the issue: https://github.com/apache/qpid-proton/pull/132 * This seems like a great improvement overall. It's easier to find stuff without needing the folklore to locate it. * The presentation of the source tree gives the project a mature look and feel. * Compiled on windows VS2012 x64 and ran tests OK. A few observations: * Why is there a directory src/extra? This seems odd after such a massive cleanup. * As a downstream consumer of the binary artifacts the minor reorganization is acceptable. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-903) Use patternfly library for charts for consistency and mantainability
[ https://issues.apache.org/jira/browse/DISPATCH-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322264#comment-16322264 ] ASF subversion and git services commented on DISPATCH-903: -- Commit cabc6f07552ee078046e01662fa81c9fa1ab56e3 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=cabc6f0 ] DISPATCH-903 Use c3 library for charts > Use patternfly library for charts for consistency and mantainability > > > Key: DISPATCH-903 > URL: https://issues.apache.org/jira/browse/DISPATCH-903 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > Switch to using the c3 charting library that is used by patternfly. This will > be more consistent with other patternfly compliant consoles. > Some homegrown features may not be possible in c3: > - stacked aggregate charts -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-353) Add pooled connection factory
Nicola Ferraro created QPIDJMS-353:
--
Summary: Add pooled connection factory
Key: QPIDJMS-353
URL: https://issues.apache.org/jira/browse/QPIDJMS-353
Project: Qpid JMS
Issue Type: Improvement
Components: qpid-jms-client
Affects Versions: 0.28.0
Reporter: Nicola Ferraro
A pooled connection factory was present in the amqp 0.x version of the library,
but is missing in the current one.
I've done some tests with Apache Camel (camel-amqp) and every message sent to a
queue results into a new connection.
A (always increasing) progressive number and a message about Sasl
authentication is printed for every message. I suspect this is a waste of
performance.
Do you plan to add this feature?
Relevant parts of the stack trace:
{code}
10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
org.apache.qpid.jms.JmsConnection - Connection
ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
amqp://localhost:5672
10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
org.apache.qpid.jms.JmsConnection - Connection
ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
amqp://localhost:5672
10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
org.apache.qpid.jms.JmsConnection - Connection
ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
amqp://localhost:5672
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-906) Document Kerberos integration
[
https://issues.apache.org/jira/browse/DISPATCH-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321885#comment-16321885
]
ASF GitHub Bot commented on DISPATCH-906:
-
Github user enkeys commented on the issue:
https://github.com/apache/qpid-dispatch/pull/241
We are trying to setup Kerberos for qpid-dispatch and it looks, that there
in /etc/sasl2/qdrouterd.conf is not mentioned option for keytab.
`keytab: /tmp/keytabs/server.keytab`
It is probably not required but it's needed to provide principal somehow. I
think that should be possible do it with external command:
`kinit -k -t /path/file.keytab myprincipal`
The next important think what's work for us is providing environment
variable KRB5_CONFIG before qdrouterd.
`KRB5_CONFIG=/tmp/qdrouterd_krb5.conf`
Else without set KRB5_CONFIG, qdrouterd get for every connection:
`SERVER (info) Connection from 1.2.3.4:56468 (to 0.0.0.0:amqp) failed:
proton:io:sasl_error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information () (Failed to authenticate
client [mech=GSSAPI])`
(My explanation is that cyrus-sasl/gssapi can't know about realms.)
So our qdrouterd_krb5.conf wit IPA conf:
```
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = example
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
example = {
kdc = ipa-server.example:88
master_kdc = ipa-server.example:88
admin_server = ipa-server.example:749
default_domain = example
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm]
.example = example
example = example
ipa-server.example = example
[dbmodules]
example = {
db_library = ipadb.so
}
```
Where "example" is TLD so can be used example.com division.example.com etc.
And we still are not able to provide any msg through (sender -> qdrouterd
-> receiver). But connection/results looks more promising.
> Document Kerberos integration
> -
>
> Key: DISPATCH-906
> URL: https://issues.apache.org/jira/browse/DISPATCH-906
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Document requirements and for accepting Kerberos authenticated connections.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #241: DISPATCH-906 Create procedure for integrating disp...
Github user enkeys commented on the issue:
https://github.com/apache/qpid-dispatch/pull/241
We are trying to setup Kerberos for qpid-dispatch and it looks, that there
in /etc/sasl2/qdrouterd.conf is not mentioned option for keytab.
`keytab: /tmp/keytabs/server.keytab`
It is probably not required but it's needed to provide principal somehow. I
think that should be possible do it with external command:
`kinit -k -t /path/file.keytab myprincipal`
The next important think what's work for us is providing environment
variable KRB5_CONFIG before qdrouterd.
`KRB5_CONFIG=/tmp/qdrouterd_krb5.conf`
Else without set KRB5_CONFIG, qdrouterd get for every connection:
`SERVER (info) Connection from 1.2.3.4:56468 (to 0.0.0.0:amqp) failed:
proton:io:sasl_error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information () (Failed to authenticate
client [mech=GSSAPI])`
(My explanation is that cyrus-sasl/gssapi can't know about realms.)
So our qdrouterd_krb5.conf wit IPA conf:
```
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = example
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
example = {
kdc = ipa-server.example:88
master_kdc = ipa-server.example:88
admin_server = ipa-server.example:749
default_domain = example
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm]
.example = example
example = example
ipa-server.example = example
[dbmodules]
example = {
db_library = ipadb.so
}
```
Where "example" is TLD so can be used example.com division.example.com etc.
And we still are not able to provide any msg through (sender -> qdrouterd
-> receiver). But connection/results looks more promising.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
