[GitHub] qpid-dispatch pull request #124: Allow passing the password via env variable
Github user dskarbek commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/124#discussion_r92076465
--- Diff: src/connection_manager.c ---
@@ -176,6 +176,46 @@ static void set_config_host(qd_server_config_t
*config, qd_entity_t* entity)
assert(config->host);
}
+static char* qd_config_ssl_profile_get_password(qd_config_ssl_profile_t*
ssl_profile)
+{
+char *pw = ssl_profile->ssl_password;
+if (!pw) return pw;
+
+/* if the "password" starts with "env:" or "env: " then the remaining
+ * text is the environment variable that contains the password
+ */
+if (strncmp(pw, "env:", 4) == 0) {
+char *env = pw + 4;
+/* skip the space if it is there */
+if (*env == ' ') ++env;
+
+const char* passwd = getenv(env);
+if (passwd) {
+free(ssl_profile->ssl_password);
+pw = ssl_profile->ssl_password = strdup(passwd);
+} else {
+qd_error(QD_ERROR_NOT_FOUND, "Failed to find a password in the
environment variable '%s'", env);
--- End diff --
Oh, you mean for the case where that isn't an env variable, but actually is
part of a password? Hmm, that's true. though, it seems like it would help you
understand what is happening faster if we log it. Is the log file less secure
than the config file? Cuz, in that case, they already have the password in the
config file.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-237) Connection doesn't always shutdown its internal threads on connection loss
[ https://issues.apache.org/jira/browse/QPIDJMS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743285#comment-15743285 ] ASF subversion and git services commented on QPIDJMS-237: - Commit c05146612527294f15529642b31d47d42bce5b47 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=c051466 ] QPIDJMS-237 Remove commented out block left in from last commit. > Connection doesn't always shutdown its internal threads on connection loss > -- > > Key: QPIDJMS-237 > URL: https://issues.apache.org/jira/browse/QPIDJMS-237 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > When the connection receives a connection level error it closes down its > internal resources but doesn't ensure that its internal task runner thread is > shutdown which can lead a build up of connection threads if external error > handler don't immediately close the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-237) Connection doesn't always shutdown its internal threads on connection loss
[ https://issues.apache.org/jira/browse/QPIDJMS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743274#comment-15743274 ] ASF subversion and git services commented on QPIDJMS-237: - Commit 4cee1c194b8c25a45edde29c4a7e0648b662b2bb in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=4cee1c1 ] QPIDJMS-237 Close down connection resource more reliably on failure On connection failure ensure that connection resources are shutdown more quickly and reliably. Remove the idle task if activated on connection loss instead of waiting on close and close down the connection executor after failure handling is complete. Also cleans up some tests that weren't closing their connections in order to free up resources quicker after the test is run. > Connection doesn't always shutdown its internal threads on connection loss > -- > > Key: QPIDJMS-237 > URL: https://issues.apache.org/jira/browse/QPIDJMS-237 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > When the connection receives a connection level error it closes down its > internal resources but doesn't ensure that its internal task runner thread is > shutdown which can lead a build up of connection threads if external error > handler don't immediately close the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-441) Support password environment variable in qdrouter config
[ https://issues.apache.org/jira/browse/DISPATCH-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-441. --- Resolution: Fixed > Support password environment variable in qdrouter config > - > > Key: DISPATCH-441 > URL: https://issues.apache.org/jira/browse/DISPATCH-441 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.6.1 >Reporter: Eric Leu >Assignee: Ted Ross > Fix For: 0.8.0 > > > Currently, ssl password is set in qdrouter config file. It would be useful > to set an environment variable name where password can be picked up. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #124: Allow passing the password via env variable
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/124 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-441) Support password environment variable in qdrouter config
[ https://issues.apache.org/jira/browse/DISPATCH-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743222#comment-15743222 ] ASF subversion and git services commented on DISPATCH-441: -- Commit 5d214bd05220eca95cff4cc892af7ee7d70dce0e in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5d214bd ] DISPATCH-441 - Allow ssl-passwords to be extracted from environment variables. Based on a contribution from Dan Skarbek. This closes #124. > Support password environment variable in qdrouter config > - > > Key: DISPATCH-441 > URL: https://issues.apache.org/jira/browse/DISPATCH-441 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.6.1 >Reporter: Eric Leu >Assignee: Ted Ross > Fix For: 0.8.0 > > > Currently, ssl password is set in qdrouter config file. It would be useful > to set an environment variable name where password can be picked up. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-557) High connection rates cause problems in the Python management agent
[ https://issues.apache.org/jira/browse/DISPATCH-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743213#comment-15743213 ] ASF GitHub Bot commented on DISPATCH-557: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/125 DISPATCH-557 - Moved management of connections from python agent to r… …outer core You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-557-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/125.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #125 commit bd86e6d00f90822b6ac0b1814e2d8a757b741a6b Author: Ganesh Murthy Date: 2016-12-12T21:30:38Z DISPATCH-557 - Moved management of connections from python agent to router core > High connection rates cause problems in the Python management agent > --- > > Key: DISPATCH-557 > URL: https://issues.apache.org/jira/browse/DISPATCH-557 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ted Ross >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 0.8.0 > > > Since connection entities are the only non-configuration (spontaneously > occurring) entities that are still managed by the Python agent, high rates of > opening and closing connections causes large CPU overhead in the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #125: DISPATCH-557 - Moved management of connecti...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/125 DISPATCH-557 - Moved management of connections from python agent to r⦠â¦outer core You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-557-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/125.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #125 commit bd86e6d00f90822b6ac0b1814e2d8a757b741a6b Author: Ganesh Murthy Date: 2016-12-12T21:30:38Z DISPATCH-557 - Moved management of connections from python agent to router core --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-441) Support password environment variable in qdrouter config
[ https://issues.apache.org/jira/browse/DISPATCH-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-441: -- Component/s: (was: Routing Engine) Container > Support password environment variable in qdrouter config > - > > Key: DISPATCH-441 > URL: https://issues.apache.org/jira/browse/DISPATCH-441 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.6.1 >Reporter: Eric Leu >Assignee: Ted Ross > Fix For: 0.8.0 > > > Currently, ssl password is set in qdrouter config file. It would be useful > to set an environment variable name where password can be picked up. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-441) Support password environment variable in qdrouter config
[ https://issues.apache.org/jira/browse/DISPATCH-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-441: -- Fix Version/s: 0.8.0 > Support password environment variable in qdrouter config > - > > Key: DISPATCH-441 > URL: https://issues.apache.org/jira/browse/DISPATCH-441 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 0.6.1 >Reporter: Eric Leu >Assignee: Ted Ross > Fix For: 0.8.0 > > > Currently, ssl password is set in qdrouter config file. It would be useful > to set an environment variable name where password can be picked up. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-441) Support password environment variable in qdrouter config
[ https://issues.apache.org/jira/browse/DISPATCH-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-441: - Assignee: Ted Ross > Support password environment variable in qdrouter config > - > > Key: DISPATCH-441 > URL: https://issues.apache.org/jira/browse/DISPATCH-441 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 0.6.1 >Reporter: Eric Leu >Assignee: Ted Ross > Fix For: 0.8.0 > > > Currently, ssl password is set in qdrouter config file. It would be useful > to set an environment variable name where password can be picked up. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-236) include all supported outcomes on producer link source
[ https://issues.apache.org/jira/browse/QPIDJMS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743085#comment-15743085 ] Rob Godfrey commented on QPIDJMS-236: - It's just that the implication of supporting the outcomes would be that you actually do something with them, and I was curious as to what a (JMS) client could actually do with released or modified. What you're actually saying is that the client only really supports two distinct outcomes (success and failure) but is liberal in how its partner communicates failure. I can sort of see how released might be used with some sort of replay/managed failover scenario, but I struggle to think of any useful semantics for sending modified to a client. > include all supported outcomes on producer link source > -- > > Key: QPIDJMS-236 > URL: https://issues.apache.org/jira/browse/QPIDJMS-236 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client handles receiving released and modified outcomes for sent > messages, but does not adverise them on the source for its producer links, > only accepted and rejected. It should advertise all of them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-237) Connection doesn't always shutdown its internal threads on connection loss
Timothy Bish created QPIDJMS-237: Summary: Connection doesn't always shutdown its internal threads on connection loss Key: QPIDJMS-237 URL: https://issues.apache.org/jira/browse/QPIDJMS-237 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.20.0 When the connection receives a connection level error it closes down its internal resources but doesn't ensure that its internal task runner thread is shutdown which can lead a build up of connection threads if external error handler don't immediately close the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #124: Allow passing the password via env variable
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/124#discussion_r92030610
--- Diff: src/connection_manager.c ---
@@ -176,6 +176,46 @@ static void set_config_host(qd_server_config_t
*config, qd_entity_t* entity)
assert(config->host);
}
+static char* qd_config_ssl_profile_get_password(qd_config_ssl_profile_t*
ssl_profile)
+{
+char *pw = ssl_profile->ssl_password;
+if (!pw) return pw;
+
+/* if the "password" starts with "env:" or "env: " then the remaining
+ * text is the environment variable that contains the password
+ */
+if (strncmp(pw, "env:", 4) == 0) {
+char *env = pw + 4;
+/* skip the space if it is there */
+if (*env == ' ') ++env;
+
+const char* passwd = getenv(env);
+if (passwd) {
+free(ssl_profile->ssl_password);
+pw = ssl_profile->ssl_password = strdup(passwd);
+} else {
+qd_error(QD_ERROR_NOT_FOUND, "Failed to find a password in the
environment variable '%s'", env);
--- End diff --
This should definitely be logged. It might be prudent to not include the
password text in the log though.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-236) include all supported outcomes on producer link source
[ https://issues.apache.org/jira/browse/QPIDJMS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742946#comment-15742946 ] Robbie Gemmell commented on QPIDJMS-236: The meaning is just what the spec says of them. In terms of effect the JMS client would currently treat them non-accepted cases as a send failure (but it could in future do something else like try resending in certain cases...no plans on that though). > include all supported outcomes on producer link source > -- > > Key: QPIDJMS-236 > URL: https://issues.apache.org/jira/browse/QPIDJMS-236 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client handles receiving released and modified outcomes for sent > messages, but does not adverise them on the source for its producer links, > only accepted and rejected. It should advertise all of them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-236) include all supported outcomes on producer link source
[ https://issues.apache.org/jira/browse/QPIDJMS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742892#comment-15742892 ] Rob Godfrey commented on QPIDJMS-236: - Out of interest, what is the meaning / intent / effect of sending released/modified back to the client? > include all supported outcomes on producer link source > -- > > Key: QPIDJMS-236 > URL: https://issues.apache.org/jira/browse/QPIDJMS-236 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client handles receiving released and modified outcomes for sent > messages, but does not adverise them on the source for its producer links, > only accepted and rejected. It should advertise all of them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742851#comment-15742851 ] ASF GitHub Bot commented on DISPATCH-209: - Github user mgoulish commented on the issue: https://github.com/apache/qpid-dispatch/pull/123 This is not working like I thought. It was using the address from the previous test. When I corrected that, it no workee. Looking into it... > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #123: DISPATCH-209 : anonymous sender test
Github user mgoulish commented on the issue: https://github.com/apache/qpid-dispatch/pull/123 This is not working like I thought. It was using the address from the previous test. When I corrected that, it no workee. Looking into it... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-66) Shims should install into a libexec directory, not into the Python site-packages path
Kim van der Riet created QPIDIT-66: -- Summary: Shims should install into a libexec directory, not into the Python site-packages path Key: QPIDIT-66 URL: https://issues.apache.org/jira/browse/QPIDIT-66 Project: Apache QPID IT Issue Type: Bug Components: Installation Reporter: Kim van der Riet Assignee: Kim van der Riet Currently, the shims are installed into a shims subdirectory in the Python install path for qpid_interop_test. This is not a standard install convention or location and will cause confusion for users. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742846#comment-15742846 ] ASF GitHub Bot commented on DISPATCH-209: - Github user mgoulish closed the pull request at: https://github.com/apache/qpid-dispatch/pull/123 > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #123: DISPATCH-209 : anonymous sender test
Github user mgoulish closed the pull request at: https://github.com/apache/qpid-dispatch/pull/123 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-52) Make qpid-interop-test installable
[ https://issues.apache.org/jira/browse/QPIDIT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-52. Resolution: Fixed Using cmake as the top-level installer, the test now installs into either a default location (/usr/local) or any other system or local path that is set into CMAKE_INSTALL_PREFIX. Python's install is called by cmake to perform the installation and is controlled in setup.py. Individual install issues are now being tracked in their own JIRAs. > Make qpid-interop-test installable > -- > > Key: QPIDIT-52 > URL: https://issues.apache.org/jira/browse/QPIDIT-52 > Project: Apache QPID IT > Issue Type: Task >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > The qpid-interop-test suite is not installable. Making it so will make it > easy for users to use against a variety of brokers in a variety of different > platforms. > The install should follow normal Python install procedures and locations as > it is primarily a Python program. The shims, although written in a variety of > different languages, are primarily required resources for the main Python > test programs. Hence they should be installed accordingly. > Local and system installs should be possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-40) Sender and Receiver threads don't stop when tests end in some error conditions
[ https://issues.apache.org/jira/browse/QPIDIT-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-40. Resolution: Fixed Adding the python daemon flag to the thread seems to have solved the outstanding issues. > Sender and Receiver threads don't stop when tests end in some error conditions > -- > > Key: QPIDIT-40 > URL: https://issues.apache.org/jira/browse/QPIDIT-40 > Project: Apache QPID IT > Issue Type: Bug >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > In some tests, a failure either in the client under test or in the test > harness itself can result in one or both of the client shims failing to stop > because they are waiting indefinitely for the test conditions to be met (such > as receiving the required number of messages, or receiving send confirmations > for sent messages). The multi-threaded approach recently added to allow for > brokerless agents such as qpid dispatch router mean that waiting for the send > and receive threads to join is no longer sufficient, and threads that are > still running must be terminated or killed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-61) Condense common code from the Python tests into a test module.
[ https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-61: --- Component/s: JMS Message Test JMS Headers and Properties Test AMQP Types Test AMQP Large Content Test > Condense common code from the Python tests into a test module. > -- > > Key: QPIDIT-61 > URL: https://issues.apache.org/jira/browse/QPIDIT-61 > Project: Apache QPID IT > Issue Type: Task > Components: AMQP Large Content Test, AMQP Types Test, JMS Headers > and Properties Test, JMS Message Test >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Each test was written independently of the others. While this is a quick way > to start, it has not lead to a lot of duplicated code and common patterns. It > would help maintenance and readability of the code if the common bits were > placed into a test library. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-63) Accomodate AMQP.Net Lite test broker
[ https://issues.apache.org/jira/browse/QPIDIT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742779#comment-15742779 ] Kim van der Riet commented on QPIDIT-63: Is this something you are considering for CI/Jenkins? > Accomodate AMQP.Net Lite test broker > > > Key: QPIDIT-63 > URL: https://issues.apache.org/jira/browse/QPIDIT-63 > Project: Apache QPID IT > Issue Type: Improvement > Environment: .NET Core or Mono to compile/run broker >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] includes a sub project > _TestAmqpBroker_ used originally as a target for self tests. This broker is > not intended to be used as an enterprise grade product but it functions > perfectly well as a target for QPIDIT tests. In fact it already passes most > of the AMQP Types tests. > This issue tracks adjustments to the QPIDIT test suite required for the Lite > test broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-63) Add shim for AMQP.Net Lite test broker
[ https://issues.apache.org/jira/browse/QPIDIT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-63: --- Component/s: (was: .Net Lite Shim) > Add shim for AMQP.Net Lite test broker > -- > > Key: QPIDIT-63 > URL: https://issues.apache.org/jira/browse/QPIDIT-63 > Project: Apache QPID IT > Issue Type: Improvement > Environment: .NET Core or Mono to compile/run broker >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] includes a sub project > _TestAmqpBroker_ used originally as a target for self tests. This broker is > not intended to be used as an enterprise grade product but it functions > perfectly well as a target for QPIDIT tests. In fact it already passes most > of the AMQP Types tests. > This issue tracks adjustments to the QPIDIT test suite required for the Lite > test broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-63) Accomodate AMQP.Net Lite test broker
[ https://issues.apache.org/jira/browse/QPIDIT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-63: --- Summary: Accomodate AMQP.Net Lite test broker (was: Add shim for AMQP.Net Lite test broker) > Accomodate AMQP.Net Lite test broker > > > Key: QPIDIT-63 > URL: https://issues.apache.org/jira/browse/QPIDIT-63 > Project: Apache QPID IT > Issue Type: Improvement > Environment: .NET Core or Mono to compile/run broker >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] includes a sub project > _TestAmqpBroker_ used originally as a target for self tests. This broker is > not intended to be used as an enterprise grade product but it functions > perfectly well as a target for QPIDIT tests. In fact it already passes most > of the AMQP Types tests. > This issue tracks adjustments to the QPIDIT test suite required for the Lite > test broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-62) Add AMQP.Net Lite client shims
[ https://issues.apache.org/jira/browse/QPIDIT-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-62: --- Component/s: .Net Lite Shim > Add AMQP.Net Lite client shims > -- > > Key: QPIDIT-62 > URL: https://issues.apache.org/jira/browse/QPIDIT-62 > Project: Apache QPID IT > Issue Type: New Feature > Components: .Net Lite Shim > Environment: .NET Core or Mono to compile/run client >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] is a mature AMQP client > and a good candidate for inclusion in this test suite. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-63) Add shim for AMQP.Net Lite test broker
[ https://issues.apache.org/jira/browse/QPIDIT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-63: --- Summary: Add shim for AMQP.Net Lite test broker (was: Accomodate AMQP.Net Lite test broker) > Add shim for AMQP.Net Lite test broker > -- > > Key: QPIDIT-63 > URL: https://issues.apache.org/jira/browse/QPIDIT-63 > Project: Apache QPID IT > Issue Type: Improvement > Components: .Net Lite Shim > Environment: .NET Core or Mono to compile/run broker >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] includes a sub project > _TestAmqpBroker_ used originally as a target for self tests. This broker is > not intended to be used as an enterprise grade product but it functions > perfectly well as a target for QPIDIT tests. In fact it already passes most > of the AMQP Types tests. > This issue tracks adjustments to the QPIDIT test suite required for the Lite > test broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-63) Accomodate AMQP.Net Lite test broker
[ https://issues.apache.org/jira/browse/QPIDIT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-63: --- Component/s: .Net Lite Shim > Accomodate AMQP.Net Lite test broker > > > Key: QPIDIT-63 > URL: https://issues.apache.org/jira/browse/QPIDIT-63 > Project: Apache QPID IT > Issue Type: Improvement > Components: .Net Lite Shim > Environment: .NET Core or Mono to compile/run broker >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] includes a sub project > _TestAmqpBroker_ used originally as a target for self tests. This broker is > not intended to be used as an enterprise grade product but it functions > perfectly well as a target for QPIDIT tests. In fact it already passes most > of the AMQP Types tests. > This issue tracks adjustments to the QPIDIT test suite required for the Lite > test broker. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-65) Add command-line controls to JMS_hdrs_props_test to control test more precisely
Kim van der Riet created QPIDIT-65:
--
Summary: Add command-line controls to JMS_hdrs_props_test to
control test more precisely
Key: QPIDIT-65
URL: https://issues.apache.org/jira/browse/QPIDIT-65
Project: Apache QPID IT
Issue Type: Improvement
Components: JMS Headers and Properties Test
Reporter: Kim van der Riet
Assignee: Kim van der Riet
The JMS hdrs_props_test needs additional command-line parameters to control the
test precisely. Since the test by default uses only the JMS_MESSAGE_TYPE for
this test, the --{include, exclude}-type paramter has no effect at present, but
should be used to change/modify the base message type. In addition, a parameter
switching on/off the headers and parameters is needed, also a control for the
type of header and type of parameters used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-2) Add command-line options to control which shims and/or AMQP type combinations to run
[
https://issues.apache.org/jira/browse/QPIDIT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved QPIDIT-2.
---
Resolution: Fixed
With the inclusion of --{include,exclude}-shim, --{include,exclude}-type and
the --no-skip flag, the type tests can be controlled down to a single test.
Tests such as amqp_large_content_test and jms_hdrs_props_test need additional
parameters to achieve single-test control, and these have been opened in
individual JIRAs. However, the parameters above do narrow the test
significantly.
> Add command-line options to control which shims and/or AMQP type combinations
> to run
>
>
> Key: QPIDIT-2
> URL: https://issues.apache.org/jira/browse/QPIDIT-2
> Project: Apache QPID IT
> Issue Type: Task
> Components: AMQP Types Test
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> Currently, simple_type_test accepts {{\-\-exclude-type}} and
> {{\-\-exclude-shim}} command-line arguments to limit the number of tests that
> are run. These arguments subtract from the list of known types and shims
> respectively.
> A comprehensive approach which allows a specific shim/type combinations to be
> specified as well as excluded needs to be developed. For example, using
> {{\-\-include-test }}, {{\-\-include-shim }} and/or
> {{\-\-include-type }} would be mutually exclusive of the
> {{\-\-exclude\-*}} counterparts, and would start with and empty set and
> include only those types listed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-64) Add command-line controls for AMQP_large_content_test to control size
Kim van der Riet created QPIDIT-64: -- Summary: Add command-line controls for AMQP_large_content_test to control size Key: QPIDIT-64 URL: https://issues.apache.org/jira/browse/QPIDIT-64 Project: Apache QPID IT Issue Type: Improvement Components: AMQP Large Content Test Reporter: Kim van der Riet Assignee: Kim van der Riet Add a command-line parameter to control the inclusion/exclusion of the size of the messages to be tested in MBytes. Currently, the test uses 1, 10, 100 (MBytes) for testing and is fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-591) Add http listener to example/test router configs in the tests directory
[ https://issues.apache.org/jira/browse/DISPATCH-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-591. --- Resolution: Fixed Assignee: Ernest Allen Fix Version/s: 0.8.0 > Add http listener to example/test router configs in the tests directory > --- > > Key: DISPATCH-591 > URL: https://issues.apache.org/jira/browse/DISPATCH-591 > Project: Qpid Dispatch > Issue Type: Task > Components: Tools >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 0.8.0 > > > Now that the routers have the ability to handle websockets directly, the > sample config files in the qpid-dispatch/tests directory should contain a > listener that is configured for http. > Only one config file in each directory needs an http listener. Also, the > listener should be on port 5673. > Once the routers can handle secure websockets traffic, the sample config > files that handle ssl should include an https listener on port 5674. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-591) Add http listener to example/test router configs in the tests directory
[ https://issues.apache.org/jira/browse/DISPATCH-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742736#comment-15742736 ] ASF subversion and git services commented on DISPATCH-591: -- Commit 7ca30cfcb760a9e5b666ff98b30dca057bd0ad1c in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7ca30cf ] DISPATCH-591 Added http=true to all A.conf files to allow serving and connecting by stand-alone console > Add http listener to example/test router configs in the tests directory > --- > > Key: DISPATCH-591 > URL: https://issues.apache.org/jira/browse/DISPATCH-591 > Project: Qpid Dispatch > Issue Type: Task > Components: Tools >Reporter: Ernest Allen > > Now that the routers have the ability to handle websockets directly, the > sample config files in the qpid-dispatch/tests directory should contain a > listener that is configured for http. > Only one config file in each directory needs an http listener. Also, the > listener should be on port 5673. > Once the routers can handle secure websockets traffic, the sample config > files that handle ssl should include an https listener on port 5674. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-2) Add command-line options to control which shims and/or AMQP type combinations to run
[
https://issues.apache.org/jira/browse/QPIDIT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742717#comment-15742717
]
ASF subversion and git services commented on QPIDIT-2:
--
Commit e622fa5798a4211ec5e74d456d945b3fe5a146e4 in qpid-interop-test's branch
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=e622fa5 ]
QPIDIT-2: Added --include-type and --exclude-type parameters, as well as
--no-skip flag to control tests
> Add command-line options to control which shims and/or AMQP type combinations
> to run
>
>
> Key: QPIDIT-2
> URL: https://issues.apache.org/jira/browse/QPIDIT-2
> Project: Apache QPID IT
> Issue Type: Task
> Components: AMQP Types Test
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> Currently, simple_type_test accepts {{\-\-exclude-type}} and
> {{\-\-exclude-shim}} command-line arguments to limit the number of tests that
> are run. These arguments subtract from the list of known types and shims
> respectively.
> A comprehensive approach which allows a specific shim/type combinations to be
> specified as well as excluded needs to be developed. For example, using
> {{\-\-include-test }}, {{\-\-include-shim }} and/or
> {{\-\-include-type }} would be mutually exclusive of the
> {{\-\-exclude\-*}} counterparts, and would start with and empty set and
> include only those types listed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-59) Create a HOWTO file on writing a new shim
[ https://issues.apache.org/jira/browse/QPIDIT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742718#comment-15742718 ] ASF subversion and git services commented on QPIDIT-59: --- Commit 73a2aa661328eaeb1e5aabd6068f3f36f5fd7889 in qpid-interop-test's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=73a2aa6 ] QPIDIT-59: Minor updates to HOWTO file > Create a HOWTO file on writing a new shim > - > > Key: QPIDIT-59 > URL: https://issues.apache.org/jira/browse/QPIDIT-59 > Project: Apache QPID IT > Issue Type: Task > Components: Documentation >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Create a file which lays out how to write a shim. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-234) set supported source outcomes on Coordinator links
[ https://issues.apache.org/jira/browse/QPIDJMS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-234. Resolution: Fixed > set supported source outcomes on Coordinator links > -- > > Key: QPIDJMS-234 > URL: https://issues.apache.org/jira/browse/QPIDJMS-234 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client is not currently setting supported outcomes on the source for its > transaction coordinator links. It should indicate the dispositions its > supports. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-592) Attempt to auto-login to the host:port that served the web page
[ https://issues.apache.org/jira/browse/DISPATCH-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-592. --- Resolution: Fixed Fix Version/s: 0.8.0 > Attempt to auto-login to the host:port that served the web page > --- > > Key: DISPATCH-592 > URL: https://issues.apache.org/jira/browse/DISPATCH-592 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 0.8.0 > > > Now that the router can service the web site directly we can bypass the > connect page by attempting to connect to the same host:port that was used to > deliver the html page. > The connect page should still be available as the 1st tab but if the > auto-connection is successful, the overview page should be displayed. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-592) Attempt to auto-login to the host:port that served the web page
[ https://issues.apache.org/jira/browse/DISPATCH-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742671#comment-15742671 ] ASF subversion and git services commented on DISPATCH-592: -- Commit 7de6ac3b51b5986ad829d709a116e9c8cfe2ed85 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7de6ac3 ] DISPATCH-592 Auto login to host:port that served stand-alone console. Move hawtio auto-login to hawtio specific code > Attempt to auto-login to the host:port that served the web page > --- > > Key: DISPATCH-592 > URL: https://issues.apache.org/jira/browse/DISPATCH-592 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Reporter: Ernest Allen >Assignee: Ernest Allen > > Now that the router can service the web site directly we can bypass the > connect page by attempting to connect to the same host:port that was used to > deliver the html page. > The connect page should still be available as the 1st tab but if the > auto-connection is successful, the overview page should be displayed. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-236) include all supported outcomes on producer link source
[ https://issues.apache.org/jira/browse/QPIDJMS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742626#comment-15742626 ] ASF subversion and git services commented on QPIDJMS-236: - Commit 21f88e6487da4d731db1002e6ab57632d65c5a35 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=21f88e6 ] QPIDJMS-236: also advertise released and modified as supported outcomes on producer link sources > include all supported outcomes on producer link source > -- > > Key: QPIDJMS-236 > URL: https://issues.apache.org/jira/browse/QPIDJMS-236 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client handles receiving released and modified outcomes for sent > messages, but does not adverise them on the source for its producer links, > only accepted and rejected. It should advertise all of them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-236) include all supported outcomes on producer link source
[ https://issues.apache.org/jira/browse/QPIDJMS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-236. Resolution: Fixed > include all supported outcomes on producer link source > -- > > Key: QPIDJMS-236 > URL: https://issues.apache.org/jira/browse/QPIDJMS-236 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client handles receiving released and modified outcomes for sent > messages, but does not adverise them on the source for its producer links, > only accepted and rejected. It should advertise all of them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-236) include all supported outcomes on producer link source
Robbie Gemmell created QPIDJMS-236: -- Summary: include all supported outcomes on producer link source Key: QPIDJMS-236 URL: https://issues.apache.org/jira/browse/QPIDJMS-236 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.20.0 The client handles receiving released and modified outcomes for sent messages, but does not adverise them on the source for its producer links, only accepted and rejected. It should advertise all of them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742544#comment-15742544 ] Robbie Gemmell commented on QPIDJMS-232: Raised QPIDJMS-235 to cover adding option not to delay the Open. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-235) add option to complete AMQP Open without waiting for a ClientID to [not] be set
Robbie Gemmell created QPIDJMS-235: -- Summary: add option to complete AMQP Open without waiting for a ClientID to [not] be set Key: QPIDJMS-235 URL: https://issues.apache.org/jira/browse/QPIDJMS-235 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Reporter: Robbie Gemmell Fix For: 0.20.0 If no ClientID was configured on the connection URI, the client delays sending the AMQP Open frame to allow either for one to be set via setClientID, or the Connection to be otherwise used and confirm no ClientID can be set. It does this since we use the container-id to carry the ClientID. If no ClientID is configured in the URI, and a Connection is created and subsequently entirely unused (either via setClientID, or createSession etc) for a period, this may delay the Open frame longer than a server will tolerate. We should add an option to provoke the AMQP connection to be Opened immediately to allow for connections without a ClientID to succeed in this scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-234) set supported source outcomes on Coordinator links
[ https://issues.apache.org/jira/browse/QPIDJMS-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742518#comment-15742518 ] ASF subversion and git services commented on QPIDJMS-234: - Commit cc2ed51e17425452539a32656867fee7a7a78944 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=cc2ed51 ] QPIDJMS-234: set supported outcomes on transaction coordinator links, add test to validate > set supported source outcomes on Coordinator links > -- > > Key: QPIDJMS-234 > URL: https://issues.apache.org/jira/browse/QPIDJMS-234 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > The client is not currently setting supported outcomes on the source for its > transaction coordinator links. It should indicate the dispositions its > supports. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[
https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742511#comment-15742511
]
Robbie Gemmell commented on QPIDJMS-232:
{quote}
Having a mechanism (on the URL?) to specify that no clientID is being supplied
makes sense...
{quote}
It would be on the URI and also the ConnectionFactory.
{quote}
the only potential issue then is with servers that have a timeout on actually
opening the AMQP connection.
{quote}
For this bit, when you say potential issue, do you just mean that If they dont
set a ClientID in the URI, and totally neglect to use the Connection theyve
created for some period, they might need to use the option?
> Perform Authentication when the remote connection is established instead of
> waiting until Connection is used
>
>
> Key: QPIDJMS-232
> URL: https://issues.apache.org/jira/browse/QPIDJMS-232
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.20.0
>
>
> Instead of waiting until the connection is used to perform authentication we
> should perform the SASL authentication if available when the connection is
> established. This allows the createConnection methods in the
> ConnectionFactory to fail fast instead of waiting until the Connection is
> used (e.g set client ID, start, createSession etc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-478) Dispatch hung in shutdown due to multiple concurrent signal handlers
[ https://issues.apache.org/jira/browse/DISPATCH-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen resolved DISPATCH-478. - Resolution: Fixed Assignee: Ulf Lilleengen Fix Version/s: 0.7.0 > Dispatch hung in shutdown due to multiple concurrent signal handlers > > > Key: DISPATCH-478 > URL: https://issues.apache.org/jira/browse/DISPATCH-478 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Ulf Lilleengen >Priority: Minor > Fix For: 0.7.0 > > > When I ran qdrouterd with perf and pressed Ctrl+C, perf would send SIGTERM as > well as SIGINT right after each other to the router. > Scenario: > The first thread would pick up and handle the first signal in > handle_signals_LH(). However, within the function, it unlocks the > qd_server->lock before calling the registered handler. > When it unlocks this lock, some other thread will pick up the second signal > and jump into the qd_server_pause() code, where it will wait indefinitely for > threads to pause (I saw this in GDB, where 1 thread was 'missing', and all > others marked as canceled). The original handler will have canceled the > thread trying to pause all others, but it is not able to jump out. > Patch: https://github.com/apache/qpid-dispatch/pull/95 > This patch ensures that only 1 signal handler can run at a time, which fixes > the issue for me. Note that it will still potentially mask signals while > handling a signal, but the current set of signals (SIGHUP, SIGQUIT, SIGINT, > SIGTERM) either shutdown the router or do nothing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-557) High connection rates cause problems in the Python management agent
[ https://issues.apache.org/jira/browse/DISPATCH-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742487#comment-15742487 ] ASF GitHub Bot commented on DISPATCH-557: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/112 > High connection rates cause problems in the Python management agent > --- > > Key: DISPATCH-557 > URL: https://issues.apache.org/jira/browse/DISPATCH-557 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ted Ross >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 0.8.0 > > > Since connection entities are the only non-configuration (spontaneously > occurring) entities that are still managed by the Python agent, high rates of > opening and closing connections causes large CPU overhead in the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #112: DISPATCH-557 - Moved management of connecti...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/112 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742479#comment-15742479 ] Rob Godfrey commented on QPIDJMS-232: - So the new behaviour is strictly superior to the prior behaviour (I didn't realise that it was opening the TCP/SSL connection and then just waiting - I presumed that it was deferring the opening of the connection until the client id was set or other work occurred). Having a mechanism (on the URL?) to specify that no clientID is being supplied makes sense... the only potential issue then is with servers that have a timeout on actually opening the AMQP connection, or those server that spontaneously send their own open and require heartbeating of their partner. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742467#comment-15742467 ] Robbie Gemmell commented on QPIDJMS-232: Yeah I don't think we need to preserve the pre-0.20.0 behaviour, I think the new behaviour is better than it, and adding an option to send the Open immediately (when no ClientID is configured) would be a further improvement to avoid the Open being delayed to allow for a ClientID. I'd use a new JIRA for that since its kinda separate and is long standing behaviour in itself. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742454#comment-15742454 ] Robbie Gemmell commented on QPIDJMS-232: I'm not sure the spec covers that case specificaly of sending heartbeats before Open. I dont know what Proton/client would do. I dont think any of our servers send before the client, so its probably not tested. As for the waiting for seconds, no I cant say I have, though qpidd and ActiveMQ both do the same. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742436#comment-15742436 ] Timothy Bish edited comment on QPIDJMS-232 at 12/12/16 4:55 PM: Yep, as Robbie pointed out we might want to make it configurable to just open immediately if no client id is expected. If we make the configuration be to go back to not doing the authentication immediately then we are back to just connect / ssl handshake and then radio silence until the connection is first used. was (Author: tabish121): Yep, as Robbie pointed out we might want to make it configurable to just open immediately if no client id is expected. If we make the configuration be to go back to not doing the authentication immediately then we are back to just open / ssl handshake and then radio silence until the connection is first used. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742436#comment-15742436 ] Timothy Bish commented on QPIDJMS-232: -- Yep, as Robbie pointed out we might want to make it configurable to just open immediately if no client id is expected. If we make the configuration be to go back to not doing the authentication immediately then we are back to just open / ssl handshake and then radio silence until the connection is first used. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-233) Update test dependency to ActiveMQ 5.14.2
[ https://issues.apache.org/jira/browse/QPIDJMS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-233. -- Resolution: Fixed > Update test dependency to ActiveMQ 5.14.2 > -- > > Key: QPIDJMS-233 > URL: https://issues.apache.org/jira/browse/QPIDJMS-233 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[
https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742429#comment-15742429
]
Rob Godfrey commented on QPIDJMS-232:
-
{quote}
The client has always done the TCP/SSL connection, then if no ClientID was set
in the URI it awaited a ClientID being set or the connection otherwise used,
e.g session creation etc, to indicate a ClientID wont be set before it did the
SASL/Open. Now the SASL will also be done regardless.
{quote}
Ah - I guess we never tested this with the Qpid Broker for Java waiting more
than a couple of seconds to set the client id... If you open a connection
without authenticating then it suspects a DoS attack :-)
> Perform Authentication when the remote connection is established instead of
> waiting until Connection is used
>
>
> Key: QPIDJMS-232
> URL: https://issues.apache.org/jira/browse/QPIDJMS-232
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.20.0
>
>
> Instead of waiting until the connection is used to perform authentication we
> should perform the SASL authentication if available when the connection is
> established. This allows the createConnection methods in the
> ConnectionFactory to fail fast instead of waiting until the Connection is
> used (e.g set client ID, start, createSession etc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-567) Slight but persistent memory leak when running java messenger producer and consumer
[
https://issues.apache.org/jira/browse/DISPATCH-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-567.
Resolution: Fixed
Fix Version/s: 0.8.0
> Slight but persistent memory leak when running java messenger producer and
> consumer
> ---
>
> Key: DISPATCH-567
> URL: https://issues.apache.org/jira/browse/DISPATCH-567
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: messenger_reproducer.tar.gz
>
>
> Steps to reproduce -
> 1. Start the router
> 2. Extract the attached file and compile using maven.
> 3. start the producer.sh and consumer.sh
> 4. top -p $(pgrep qdrouterd)
> Output of top at different times (memory keeps creeping up
> {noformat}
> 14437 gmurthy 20 0 547708 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 548512 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 549040 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 550228 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742422#comment-15742422 ] Rob Godfrey commented on QPIDJMS-232: - Yeah - I forget exactly how all the DoD / heartbeating timeouts work in the Java Broker... I *think* the above is probably safe (since the time from TCP connection open to authenticated is short, so it will avoid the suspected DoS timeout, and the heartbeating timeout probably won't come into effect until it receives an open frame from the client), however it would be (AMQP) spec compliant for the broker to issue an open without waiting for the client, and for that open to include a heartbeat timeout... does proton/the JMS client respect that? I'd also need to check up on whether it is even legal to send empty heartbeating frames before you send an open (I can't say it was a case we ever considered). In general I agree that doing the connect/auth up front is the best thing to do... but I think that having the behaviour configurable to improve interoperability would make sense > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-567) Slight but persistent memory leak when running java messenger producer and consumer
[
https://issues.apache.org/jira/browse/DISPATCH-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-567:
--
Assignee: Ganesh Murthy
> Slight but persistent memory leak when running java messenger producer and
> consumer
> ---
>
> Key: DISPATCH-567
> URL: https://issues.apache.org/jira/browse/DISPATCH-567
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Attachments: messenger_reproducer.tar.gz
>
>
> Steps to reproduce -
> 1. Start the router
> 2. Extract the attached file and compile using maven.
> 3. start the producer.sh and consumer.sh
> 4. top -p $(pgrep qdrouterd)
> Output of top at different times (memory keeps creeping up
> {noformat}
> 14437 gmurthy 20 0 547708 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 548512 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 549040 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 550228 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-567) Slight but persistent memory leak when running java messenger producer and consumer
[
https://issues.apache.org/jira/browse/DISPATCH-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742421#comment-15742421
]
Ganesh Murthy commented on DISPATCH-567:
This issue has been fixed as a direct result of the fix to DISPATCH-582.
There are two cases in this issue
1. Dont set the outgoing window on messenger - will send presettled messages
2. Set the outgoing window on messenger (mng.setOutgoingWindow(1))
In both cases, the memory leak seems to have stopped.
Marking this issue as fixed
> Slight but persistent memory leak when running java messenger producer and
> consumer
> ---
>
> Key: DISPATCH-567
> URL: https://issues.apache.org/jira/browse/DISPATCH-567
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
> Attachments: messenger_reproducer.tar.gz
>
>
> Steps to reproduce -
> 1. Start the router
> 2. Extract the attached file and compile using maven.
> 3. start the producer.sh and consumer.sh
> 4. top -p $(pgrep qdrouterd)
> Output of top at different times (memory keeps creeping up
> {noformat}
> 14437 gmurthy 20 0 547708 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 548512 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 549040 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> 14437 gmurthy 20 0 550228 19732 8608 S 0.0 0.1 0:00.08 qdrouterd
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742414#comment-15742414 ] ASF subversion and git services commented on QPIDJMS-232: - Commit 22bbb5da45f03f6534af85d056aa249bf9e51ac0 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=22bbb5d ] QPIDJMS-232 Perform authentication on transport connect Do the authentication on transport connect as opposed to waiting until the Connection is first used to allow for early detection of a connect failure due to do bad credentials. Connection will now fail from the ConnectionFactory createConnection call if the user cannot be authenticated instead of waiting until the connection is used. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-233) Update test dependency to ActiveMQ 5.14.2
[ https://issues.apache.org/jira/browse/QPIDJMS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742402#comment-15742402 ] ASF subversion and git services commented on QPIDJMS-233: - Commit ae1ce86710188b05f1fa2d3cfcc018c2c72591cd in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=ae1ce86 ] QPIDJMS-233 Update ActiveMQ dependency to 5.14.2 > Update test dependency to ActiveMQ 5.14.2 > -- > > Key: QPIDJMS-233 > URL: https://issues.apache.org/jira/browse/QPIDJMS-233 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-234) set supported source outcomes on Coordinator links
Robbie Gemmell created QPIDJMS-234: -- Summary: set supported source outcomes on Coordinator links Key: QPIDJMS-234 URL: https://issues.apache.org/jira/browse/QPIDJMS-234 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.20.0 The client is not currently setting supported outcomes on the source for its transaction coordinator links. It should indicate the dispositions its supports. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-232: --- Summary: Perform Authentication when the remote connection is established instead of waiting until Connection is used (was: Perform Authentication when the remote connection is established instead of waiting until Connection start) > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection start
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-232: --- Description: Instead of waiting until the connection is used to perform authentication we should perform the SASL authentication if available when the connection is established. This allows the createConnection methods in the ConnectionFactory to fail fast instead of waiting until the Connection is used (e.g set client ID, start, createSession etc) (was: Instead of waiting until the connection is started to perform authentication we should perform the SASL authentication if available when the connection is established. This allows the createConnection methods in the ConnectionFactory to fail fast instead of waiting until the Connection is later started or a client ID is set. ) > Perform Authentication when the remote connection is established instead of > waiting until Connection start > -- > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-233) Update test dependency to ActiveMQ 5.14.2
Timothy Bish created QPIDJMS-233: Summary: Update test dependency to ActiveMQ 5.14.2 Key: QPIDJMS-233 URL: https://issues.apache.org/jira/browse/QPIDJMS-233 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.20.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742376#comment-15742376 ] Robbie Gemmell commented on QPIDJMS-232: The description was for when you dont set a CientID in the URI. If you do it does everything immediately. The client has always done the TCP/SSL connection, then if no ClientID was set in the URI it awaited a ClientID being set or the connection otherwise used, e.g session creation etc, to indicate a ClientID wont be set before it did the SASL/Open. Now the SASL will also be done regardless. An option could be added later as you suggest, basically be controlling that a clientID will never be set and having the open sent immediatley too. > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection start
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742344#comment-15742344 ] Timothy Bish commented on QPIDJMS-232: -- Current plan would be to not send the open frame until the start method or client id is set as that is necessary for the JMS API compliance bit of the JMS client. > Perform Authentication when the remote connection is established instead of > waiting until Connection start > -- > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is started to perform authentication > we should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > later started or a client ID is set. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-296) segfault on router startup
[
https://issues.apache.org/jira/browse/DISPATCH-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-296:
--
Assignee: Ganesh Murthy
> segfault on router startup
> --
>
> Key: DISPATCH-296
> URL: https://issues.apache.org/jira/browse/DISPATCH-296
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: multiconnect.conf
>
>
> Starting up a router with a couple of connectors (connectingto qpidd
> instances in my case), the router occasionally (maybe one in five) crashes
> with a segfault.
> {noformat}
> (gdb) bt
> #0 0x7629c76e in sasl_client_add_plugin () from /lib64/libsasl2.so.3
> #1 0x7629cf58 in sasl_client_init () from /lib64/libsasl2.so.3
> #2 0x7796ecff in pni_init_client
> (transport=transport@entry=0x7fffdc008fc0) at
> /home/gordon/projects/proton/proton-c/src/sasl/cyrus_sasl.c:115
> #3 0x7796e87e in pn_do_mechanisms (transport=0x7fffdc008fc0,
> frame_type=, channel=, args=,
> payload=)
> at /home/gordon/projects/proton/proton-c/src/sasl/sasl.c:703
> #4 0x77959b26 in pni_dispatch_action (payload=0x7fffe96f2360,
> args=0x7fffdc0091c0, channel=0, frame_type=1 '\001', lcode=,
> transport=0x7fffdc008fc0)
> at /home/gordon/projects/proton/proton-c/src/dispatcher/dispatcher.c:74
> #5 pni_dispatch_frame (args=0x7fffdc0091c0, transport=0x7fffdc008fc0,
> frame=...) at
> /home/gordon/projects/proton/proton-c/src/dispatcher/dispatcher.c:116
> #6 pn_dispatcher_input (transport=0x7fffdc008fc0, bytes=0x7fffdc00f358 "",
> available=0, batch=false, halt=0x7fffdc009144) at
> /home/gordon/projects/proton/proton-c/src/dispatcher/dispatcher.c:135
> #7 0x7795fbba in transport_consume
> (transport=transport@entry=0x7fffdc008fc0) at
> /home/gordon/projects/proton/proton-c/src/transport/transport.c:1751
> #8 0x779630d2 in pn_transport_process
> (transport=transport@entry=0x7fffdc008fc0, size=) at
> /home/gordon/projects/proton/proton-c/src/transport/transport.c:2860
> #9 0x77bb08e3 in qdpn_connector_process (c=0x7fffdc0068c0) at
> /home/gordon/projects/dispatch/src/posix/driver.c:761
> #10 0x77bc3a91 in process_connector (cxtr=0x7fffdc0068c0,
> qd_server=0x702b50) at /home/gordon/projects/dispatch/src/server.c:683
> #11 thread_run (arg=0x87b9b0) at
> /home/gordon/projects/dispatch/src/server.c:958
> #12 0x7772660a in start_thread () from /lib64/libpthread.so.0
> #13 0x76c8ba4d in clone () from /lib64/libc.so.6
> {noformat}
> other threads:
> {noformat}
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x77fd1180 (LWP 19319))]
> #0 0x7772e89d in __lll_lock_wait () from /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7772e89d in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x777289cd in pthread_mutex_lock () from /lib64/libpthread.so.0
> #2 0x77bb1239 in sys_mutex_lock (mutex=0x702da0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:70
> #3 0x77bc4723 in qd_timer (qd=qd@entry=0x604240,
> cb=cb@entry=0x77bc11b0 , context=context@entry=0x702b50) at
> /home/gordon/projects/dispatch/src/timer.c:89
> #4 0x77bc3f33 in qd_server_run (qd=0x604240) at
> /home/gordon/projects/dispatch/src/server.c:1349
> #5 0x00401ac7 in main_process
> (config_path=config_path@entry=0x7fffe090
> "./etc/qpid-dispatch/multiconnect.conf",
> python_pkgdir=python_pkgdir@entry=0x402468
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python",
> fd=fd@entry=2) at /home/gordon/projects/dispatch/router/src/main.c:135
> #6 0x004017b7 in main (argc=3, argv=0x7fffdd08) at
> /home/gordon/projects/dispatch/router/src/main.c:335
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x7fffea30f700 (LWP 19323))]
> #0 0x7772bb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7772bb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x77bb133f in sys_cond_wait (cond=,
> held_mutex=0x8624a0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x77bbba1d in router_core_thread (arg=0x862180) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7772660a in start_thread () from /lib64/libpthread.so.0
> #4 0x76c8ba4d in clone () from /lib64/libc.so.6
> (gdb) thread 4
> [Switching to thread 4 (Thread 0x7fffe8ef2700 (LWP 19325))]
> #0 0x77deaadf in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
> (gdb) bt
> #0 0x77deaadf in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
> #1 0x77df1db0 in _dl_r
[jira] [Resolved] (DISPATCH-296) segfault on router startup
[
https://issues.apache.org/jira/browse/DISPATCH-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-296.
Resolution: Fixed
Fix Version/s: 0.8.0
The fix to PROTON-992 seems to have fixed this issue. I could not get the
router to crash with two qpidd brokers and the attached router conf file.
> segfault on router startup
> --
>
> Key: DISPATCH-296
> URL: https://issues.apache.org/jira/browse/DISPATCH-296
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Gordon Sim
> Fix For: 0.8.0
>
> Attachments: multiconnect.conf
>
>
> Starting up a router with a couple of connectors (connectingto qpidd
> instances in my case), the router occasionally (maybe one in five) crashes
> with a segfault.
> {noformat}
> (gdb) bt
> #0 0x7629c76e in sasl_client_add_plugin () from /lib64/libsasl2.so.3
> #1 0x7629cf58 in sasl_client_init () from /lib64/libsasl2.so.3
> #2 0x7796ecff in pni_init_client
> (transport=transport@entry=0x7fffdc008fc0) at
> /home/gordon/projects/proton/proton-c/src/sasl/cyrus_sasl.c:115
> #3 0x7796e87e in pn_do_mechanisms (transport=0x7fffdc008fc0,
> frame_type=, channel=, args=,
> payload=)
> at /home/gordon/projects/proton/proton-c/src/sasl/sasl.c:703
> #4 0x77959b26 in pni_dispatch_action (payload=0x7fffe96f2360,
> args=0x7fffdc0091c0, channel=0, frame_type=1 '\001', lcode=,
> transport=0x7fffdc008fc0)
> at /home/gordon/projects/proton/proton-c/src/dispatcher/dispatcher.c:74
> #5 pni_dispatch_frame (args=0x7fffdc0091c0, transport=0x7fffdc008fc0,
> frame=...) at
> /home/gordon/projects/proton/proton-c/src/dispatcher/dispatcher.c:116
> #6 pn_dispatcher_input (transport=0x7fffdc008fc0, bytes=0x7fffdc00f358 "",
> available=0, batch=false, halt=0x7fffdc009144) at
> /home/gordon/projects/proton/proton-c/src/dispatcher/dispatcher.c:135
> #7 0x7795fbba in transport_consume
> (transport=transport@entry=0x7fffdc008fc0) at
> /home/gordon/projects/proton/proton-c/src/transport/transport.c:1751
> #8 0x779630d2 in pn_transport_process
> (transport=transport@entry=0x7fffdc008fc0, size=) at
> /home/gordon/projects/proton/proton-c/src/transport/transport.c:2860
> #9 0x77bb08e3 in qdpn_connector_process (c=0x7fffdc0068c0) at
> /home/gordon/projects/dispatch/src/posix/driver.c:761
> #10 0x77bc3a91 in process_connector (cxtr=0x7fffdc0068c0,
> qd_server=0x702b50) at /home/gordon/projects/dispatch/src/server.c:683
> #11 thread_run (arg=0x87b9b0) at
> /home/gordon/projects/dispatch/src/server.c:958
> #12 0x7772660a in start_thread () from /lib64/libpthread.so.0
> #13 0x76c8ba4d in clone () from /lib64/libc.so.6
> {noformat}
> other threads:
> {noformat}
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x77fd1180 (LWP 19319))]
> #0 0x7772e89d in __lll_lock_wait () from /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7772e89d in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x777289cd in pthread_mutex_lock () from /lib64/libpthread.so.0
> #2 0x77bb1239 in sys_mutex_lock (mutex=0x702da0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:70
> #3 0x77bc4723 in qd_timer (qd=qd@entry=0x604240,
> cb=cb@entry=0x77bc11b0 , context=context@entry=0x702b50) at
> /home/gordon/projects/dispatch/src/timer.c:89
> #4 0x77bc3f33 in qd_server_run (qd=0x604240) at
> /home/gordon/projects/dispatch/src/server.c:1349
> #5 0x00401ac7 in main_process
> (config_path=config_path@entry=0x7fffe090
> "./etc/qpid-dispatch/multiconnect.conf",
> python_pkgdir=python_pkgdir@entry=0x402468
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python",
> fd=fd@entry=2) at /home/gordon/projects/dispatch/router/src/main.c:135
> #6 0x004017b7 in main (argc=3, argv=0x7fffdd08) at
> /home/gordon/projects/dispatch/router/src/main.c:335
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x7fffea30f700 (LWP 19323))]
> #0 0x7772bb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7772bb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x77bb133f in sys_cond_wait (cond=,
> held_mutex=0x8624a0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x77bbba1d in router_core_thread (arg=0x862180) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7772660a in start_thread () from /lib64/libpthread.so.0
> #4 0x76c8ba4d in clone () from /lib64/libc.so.6
> (gdb) thread 4
> [Switching to thread 4 (Thread 0x7fffe8ef2700 (LWP 19325))]
> #0 0x77deaadf in _dl_fixup () from /lib64/ld-linux-
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection start
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742291#comment-15742291 ] Rob Godfrey commented on QPIDJMS-232: - Purely out of curiosity - if you are allowing the client Id to be set "later" is the plan here that you will do SASL negotiation (if any) / TLS handshake (if applicable) then wait before sending the open frame? This sort of behaviour may give rise to timeout exceptions on servers that expect the connect - authenticate - open sequence to happen in quick succession (the Qpid Java Broker for instance has some timeouts in place here) certainly it seems possible that you'll run into issues where one side is expecting heartbeating. As such it would seem prudent to make this behaviour configurable. > Perform Authentication when the remote connection is established instead of > waiting until Connection start > -- > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is started to perform authentication > we should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > later started or a client ID is set. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection start
Timothy Bish created QPIDJMS-232: Summary: Perform Authentication when the remote connection is established instead of waiting until Connection start Key: QPIDJMS-232 URL: https://issues.apache.org/jira/browse/QPIDJMS-232 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.20.0 Instead of waiting until the connection is started to perform authentication we should perform the SASL authentication if available when the connection is established. This allows the createConnection methods in the ConnectionFactory to fail fast instead of waiting until the Connection is later started or a client ID is set. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-228) Connection close can use wrong timeout value and stall
[ https://issues.apache.org/jira/browse/QPIDJMS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-228. -- Resolution: Fixed > Connection close can use wrong timeout value and stall > -- > > Key: QPIDJMS-228 > URL: https://issues.apache.org/jira/browse/QPIDJMS-228 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > When closing the JMS Connection the closeTimeout value should be used to > control how long to wait before failing the close request and continue the > shutdown procedure. There is a code path that will instead use the > requestTimeout value which defaults to infinite wait and can lead to a > close() call that is hung waiting on server response which might in some > cases never come. > Close on other resources such as Session, Producer and Consumer are also > using requestTimeout and should really be using the closeTimeout to be > consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7587) [Java Broker] add support for enveloping 0-9/0-10 messages on the 1-0 protocol
[ https://issues.apache.org/jira/browse/QPID-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742060#comment-15742060 ] ASF subversion and git services commented on QPID-7587: --- Commit 1773795 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1773795 ] QPID-7587 : Add support for enveloping messages from 0-x protocols using the 1.0 transport > [Java Broker] add support for enveloping 0-9/0-10 messages on the 1-0 protocol > -- > > Key: QPID-7587 > URL: https://issues.apache.org/jira/browse/QPID-7587 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > AMQP 1.0 supports the notion of different message formats, with only message > format 0 being defined in the core specification. > We can utilise different message formats to support the transport of AMQP 0-x > messages over AMQP 1.0. The intended use case is for broker to broker > federation where we do not wish to lose fidelity to the original message, but > we also do not want to have to set up separate inter-broker links for > transporting different messages of differing original protocols. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7587) [Java Broker] add support for enveloping 0-9/0-10 messages on the 1-0 protocol
Rob Godfrey created QPID-7587: - Summary: [Java Broker] add support for enveloping 0-9/0-10 messages on the 1-0 protocol Key: QPID-7587 URL: https://issues.apache.org/jira/browse/QPID-7587 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey AMQP 1.0 supports the notion of different message formats, with only message format 0 being defined in the core specification. We can utilise different message formats to support the transport of AMQP 0-x messages over AMQP 1.0. The intended use case is for broker to broker federation where we do not wish to lose fidelity to the original message, but we also do not want to have to set up separate inter-broker links for transporting different messages of differing original protocols. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7583) [Java Broker] On AMQP 1.0 ensure Flow is sent to client when producer flow control changes state
[ https://issues.apache.org/jira/browse/QPID-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7583. -- Resolution: Fixed The changes look good to me > [Java Broker] On AMQP 1.0 ensure Flow is sent to client when producer flow > control changes state > > > Key: QPID-7583 > URL: https://issues.apache.org/jira/browse/QPID-7583 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-6.2 > > > Currently the broker does not always send the Flow command to the client when > the broker wants to toggle producer side flow control. > This can lead to the broker thinking the client is active while in fact it is > still blocked. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7583) [Java Broker] On AMQP 1.0 ensure Flow is sent to client when producer flow control changes state
[ https://issues.apache.org/jira/browse/QPID-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7583: - Fix Version/s: qpid-java-6.2 > [Java Broker] On AMQP 1.0 ensure Flow is sent to client when producer flow > control changes state > > > Key: QPID-7583 > URL: https://issues.apache.org/jira/browse/QPID-7583 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-6.2 > > > Currently the broker does not always send the Flow command to the client when > the broker wants to toggle producer side flow control. > This can lead to the broker thinking the client is active while in fact it is > still blocked. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
