[jira] [Updated] (PROTON-1007) Docs: pn_message_set_address(): Address is undocumented

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1007:

Component/s: proton-c

> Docs: pn_message_set_address(): Address is undocumented
> ---
>
> Key: PROTON-1007
> URL: https://issues.apache.org/jira/browse/PROTON-1007
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Graham Leggett
>Assignee: Justin Ross
>  Labels: docs
> Fix For: 0.17.0
>
>
> In the docs for the following function, the format of the "address" parameter 
> is unspecified:
> http://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__message.html#gadae5d992568a088c561e5ddcdde13705
> This function should either describe the address format, or link to the part 
> of the documentation that does.



--
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] (PROTON-999) Docs: pn_messenger_subscribe(): "source" is undocumented

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-999:
---
Labels: docs messenger  (was: documentation messenger)

> Docs: pn_messenger_subscribe(): "source" is undocumented
> 
>
> Key: PROTON-999
> URL: https://issues.apache.org/jira/browse/PROTON-999
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Graham Leggett
>Assignee: Justin Ross
>  Labels: docs, messenger
>
> The pn_messenger_subscribe() function is documented to take a const char * as 
> a "source":
> https://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__messenger.html#gaf1f1bfe4894d971f0b8d679bcab5cae6
> The definition of a "source" isn't specified, nor is the acceptable source 
> format specified.
> In addition, it isn't specified in the docs whether this function must be 
> called once, or whether it can be called multiple times. Reverse engineering 
> the source seems to indicate that it should be called just once, and if you 
> call it multiple times the underlying event loop will be corrupted.



--
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] (PROTON-1347) Container prints to stderr on connection timed out

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1347:

Fix Version/s: 0.17.0

> Container prints to stderr on connection timed out
> --
>
> Key: PROTON-1347
> URL: https://issues.apache.org/jira/browse/PROTON-1347
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Affects Versions: 0.14.0
>Reporter: Mike Bonnet
>Assignee: Justin Ross
>Priority: Minor
> Fix For: 0.17.0
>
>
> If you're using a Container to connect to a broker, and the broker is 
> unresponsive and the connection times out, this is printed to stderr:
> ERROR:root:proton:io: recv: Connection timed out
> Libraries generally shouldn't print directly to the console, especially when 
> the error can be handled in the code.



--
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

[dskarbek]

Github user dskarbek commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/124#discussion_r91815078
  
--- 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);
+}
+return pw;
+}
+
+/* if the "password" starts with "literal:" or "literal: " then
+ * the remaining text is the password and the heading should be
+ * stripped off
+ */
+if (strncmp(pw, "literal:", 8) == 0) {
+/* skip the "literal:" header */
+pw += 8;
+/* skip the space if it is there */
+if (*pw == ' ') ++pw;
+/* return a pointer into the middle of the string where the 
literal password starts */
+return pw;
--- End diff --

Not a problem unless I'm wrong about the memory management of this pointer.


---
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

[GitHub] qpid-dispatch pull request #124: Allow passing the password via env variable

[dskarbek]

Github user dskarbek commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/124#discussion_r91815006
  
--- 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 --

or, would you rather just return the password string as is and not register 
an error in-case it is an actual password?  If it is referring to an env var 
that missed getting set there's next to zero chance it will work, so better to 
catch the error sooner at the source so we can log it appropriately, but this 
does mean that someone using "env:foobar" as a password will suddenly stop 
working.


---
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

[GitHub] qpid-dispatch pull request #124: Allow passing the password via env variable

[dskarbek]

Github user dskarbek commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/124#discussion_r91814838
  
--- 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);
--- End diff --

Hmm, or, if I'm correct that the config->ssl_password is never directly 
free'd, then I could just pass back the static getenv() returned string as the 
value (except I'd have to cast away const).  Then I don't have to change the 
string held in ssl_profile.  Thoughts?  Is my memory management correct here 
(and below) that the config->ssl_password is a reference to memory that it 
doesn't own and free is not called on 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

[GitHub] qpid-dispatch pull request #124: Allow passing the password via env variable

[dskarbek]

GitHub user dskarbek opened a pull request:

https://github.com/apache/qpid-dispatch/pull/124

Allow passing the password via env variable

Allows for the password in the config to actually be the name of the 
environment variable that contains the password.  This is indicated by 
prefixing the value with "env:".  We also add the option to prefix with 
"literal:" which indicates that it is a raw password.  That way, you can still 
give "env:SHELL" as a password, if that's what you really want to use, you 
would just have to list it as "literal:env:SHELL" in the config.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dskarbek/qpid-dispatch 
allow_password_in_env_var

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/124.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 #124


commit f84a135084de49f900a845ff934e212b03ec7957
Author: Daniel Skarbek 
Date:   2016-12-09T01:02:39Z

Allow the password config to point to an environment variable with the 
actual password




---
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] (PROTON-1358) Memory leak in proactor receiver example if I add a timeout

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1358:

Fix Version/s: 0.17.0

> Memory leak in proactor receiver example if I add a timeout
> ---
>
> Key: PROTON-1358
> URL: https://issues.apache.org/jira/browse/PROTON-1358
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Jiri Danek
> Fix For: 0.17.0
>
> Attachments: AddressSanitizer.log, 
> leak-f1c681da874efe3b168d6bd00e1de53c5a3823ea, timeout.patch
>
>
> Modify the {{examples/c/proactor/receive.c}} with the attached patch. Then 
> build and run like this
> {noformat}
> $ nc -l 5672 < leak-f1c681da874efe3b168d6bd00e1de53c5a3823ea
> $ valgrind --leak-check=full ./libuv_receive -a 
> 127.0.0.1:5672/jms.queue.example
> ==19440== Memcheck, a memory error detector
> ==19440== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==19440== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==19440== Command: ./libuv_receive -a 127.0.0.1:5672/jms.queue.example
> ==19440== 
> ==19440== 
> ==19440== HEAP SUMMARY:
> ==19440== in use at exit: 67,206 bytes in 452 blocks
> ==19440==   total heap usage: 470 allocs, 18 frees, 72,587 bytes allocated
> ==19440== 
> ==19440== 67,206 (288 direct, 66,918 indirect) bytes in 1 blocks are 
> definitely lost in loss record 450 of 450
> ==19440==at 0x4C2CA40: calloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==19440==by 0x4E50E4E: pn_object_new (object.c:202)
> ==19440==by 0x4E51160: pn_class_new (object.c:61)
> ==19440==by 0x4E6310A: pn_connection (engine.c:514)
> ==19440==by 0x4043B0: main (receive.c:203)
> ==19440== 
> ==19440== LEAK SUMMARY:
> ==19440==definitely lost: 288 bytes in 1 blocks
> ==19440==indirectly lost: 66,918 bytes in 451 blocks
> ==19440==  possibly lost: 0 bytes in 0 blocks
> ==19440==still reachable: 0 bytes in 0 blocks
> ==19440== suppressed: 0 bytes in 0 blocks
> ==19440== 
> ==19440== For counts of detected and suppressed errors, rerun with: -v
> ==19440== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> {noformat}
> Log from when I enabled AddressSanitizer instead of Valgrind is in attachment.
> The file {{leak-f1c681da874efe3b168d6bd00e1de53c5a3823ea}} is the same as in 
> PROTON-1357.



--
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] (PROTON-1358) Memory leak in proactor receiver example if I add a timeout

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1358:

Assignee: Alan Conway

> Memory leak in proactor receiver example if I add a timeout
> ---
>
> Key: PROTON-1358
> URL: https://issues.apache.org/jira/browse/PROTON-1358
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Fix For: 0.17.0
>
> Attachments: AddressSanitizer.log, 
> leak-f1c681da874efe3b168d6bd00e1de53c5a3823ea, timeout.patch
>
>
> Modify the {{examples/c/proactor/receive.c}} with the attached patch. Then 
> build and run like this
> {noformat}
> $ nc -l 5672 < leak-f1c681da874efe3b168d6bd00e1de53c5a3823ea
> $ valgrind --leak-check=full ./libuv_receive -a 
> 127.0.0.1:5672/jms.queue.example
> ==19440== Memcheck, a memory error detector
> ==19440== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==19440== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==19440== Command: ./libuv_receive -a 127.0.0.1:5672/jms.queue.example
> ==19440== 
> ==19440== 
> ==19440== HEAP SUMMARY:
> ==19440== in use at exit: 67,206 bytes in 452 blocks
> ==19440==   total heap usage: 470 allocs, 18 frees, 72,587 bytes allocated
> ==19440== 
> ==19440== 67,206 (288 direct, 66,918 indirect) bytes in 1 blocks are 
> definitely lost in loss record 450 of 450
> ==19440==at 0x4C2CA40: calloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==19440==by 0x4E50E4E: pn_object_new (object.c:202)
> ==19440==by 0x4E51160: pn_class_new (object.c:61)
> ==19440==by 0x4E6310A: pn_connection (engine.c:514)
> ==19440==by 0x4043B0: main (receive.c:203)
> ==19440== 
> ==19440== LEAK SUMMARY:
> ==19440==definitely lost: 288 bytes in 1 blocks
> ==19440==indirectly lost: 66,918 bytes in 451 blocks
> ==19440==  possibly lost: 0 bytes in 0 blocks
> ==19440==still reachable: 0 bytes in 0 blocks
> ==19440== suppressed: 0 bytes in 0 blocks
> ==19440== 
> ==19440== For counts of detected and suppressed errors, rerun with: -v
> ==19440== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> {noformat}
> Log from when I enabled AddressSanitizer instead of Valgrind is in attachment.
> The file {{leak-f1c681da874efe3b168d6bd00e1de53c5a3823ea}} is the same as in 
> PROTON-1357.



--
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] (PROTON-1360) pn_strndup (util.c:150) Invalid write of size 1

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1360:

Fix Version/s: 0.17.0

> pn_strndup (util.c:150) Invalid write of size 1
> ---
>
> Key: PROTON-1360
> URL: https://issues.apache.org/jira/browse/PROTON-1360
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.15.0, 0.16.0
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Fix For: 0.17.0
>
> Attachments: crash-cacbe90ba41be2fb116697da7a90bfd716812c7b, 
> minimized-from-9a77cc2e90542c5aa1e55a86d2c9920febb0ad68
>
>
> {noformat}
> nc -l 127.0.0.1 5672 < ./crash-cacbe90ba41be2fb116697da7a90bfd716812c7b
> {noformat}
> On 0.15.0, do
> {noformat}
> [qpid-proton-0.15.0/build/examples/c/messenger] $ valgrind ./recv 
> 127.0.0.1/jms.queue.example
> ==5749== Memcheck, a memory error detector
> ==5749== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==5749== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==5749== Command: ./recv 127.0.0.1/jms.queue.example
> ==5749== 
> ==5749== Invalid write of size 1
> ==5749==at 0x4C2D13C: __strncpy_sse2_unaligned (vg_replace_strmem.c:548)
> ==5749==by 0x4E4AD80: pn_strndup (util.c:259)
> ==5749==by 0x4E5A7BE: pn_bytes_strdup (transport.c:1153)
> ==5749==by 0x4E5A7BE: pn_do_open (transport.c:1198)
> ==5749==by 0x4E52B6A: pni_dispatch_action (dispatcher.c:74)
> ==5749==by 0x4E52B6A: pni_dispatch_frame (dispatcher.c:116)
> ==5749==by 0x4E52B6A: pn_dispatcher_input (dispatcher.c:135)
> ==5749==by 0x4E5906B: pn_input_read_amqp (transport.c:2523)
> ==5749==by 0x4E59129: transport_consume (transport.c:1799)
> ==5749==by 0x4E5C971: pn_transport_process (transport.c:2908)
> ==5749==by 0x4E646F3: pni_connection_readable (messenger.c:262)
> ==5749==by 0x4E6482F: pn_messenger_process (messenger.c:1367)
> ==5749==by 0x4E649E0: pn_messenger_tsync (messenger.c:1439)
> ==5749==by 0x4E64F94: pn_messenger_recv (messenger.c:2212)
> ==5749==by 0x4012A4: main (recv.c:131)
> ==5749==  Address 0x772d641 is 0 bytes after a block of size 1 alloc'd
> ==5749==at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
> ==5749==by 0x4E4AD6A: pn_strndup (util.c:257)
> ==5749==by 0x4E5A7BE: pn_bytes_strdup (transport.c:1153)
> ==5749==by 0x4E5A7BE: pn_do_open (transport.c:1198)
> ==5749==by 0x4E52B6A: pni_dispatch_action (dispatcher.c:74)
> ==5749==by 0x4E52B6A: pni_dispatch_frame (dispatcher.c:116)
> ==5749==by 0x4E52B6A: pn_dispatcher_input (dispatcher.c:135)
> ==5749==by 0x4E5906B: pn_input_read_amqp (transport.c:2523)
> ==5749==by 0x4E59129: transport_consume (transport.c:1799)
> ==5749==by 0x4E5C971: pn_transport_process (transport.c:2908)
> ==5749==by 0x4E646F3: pni_connection_readable (messenger.c:262)
> ==5749==by 0x4E6482F: pn_messenger_process (messenger.c:1367)
> ==5749==by 0x4E649E0: pn_messenger_tsync (messenger.c:1439)
> ==5749==by 0x4E64F94: pn_messenger_recv (messenger.c:2212)
> ==5749==by 0x4012A4: main (recv.c:131)
> ==5749== 
> Address: jms.queue.example
> Subject: (no subject)
> Content: "test message: 26"
> {noformat}
> On 0.16.0 you can do
> {noformat}
> [proactor]$ valgrind ./libuv_receive -a 127.0.0.1:5672/jms.queue.example -m 2
> ==26215== Memcheck, a memory error detector
> ==26215== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==26215== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==26215== Command: ./libuv_receive -a 127.0.0.1:5672/jms.queue.example -m 2
> ==26215== 
> ==26215== Invalid write of size 1
> ==26215==at 0x4C2E284: __strncpy_sse2_unaligned (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26215==by 0x4E4CF71: pn_strndup (util.c:150)
> ==26215==by 0x4E5B0EE: pn_bytes_strdup (transport.c:1154)
> ==26215==by 0x4E5B0EE: pn_do_open (transport.c:1199)
> ==26215==by 0x4E53270: pni_dispatch_action (dispatcher.c:74)
> ==26215==by 0x4E53270: pni_dispatch_frame (dispatcher.c:116)
> ==26215==by 0x4E53270: pn_dispatcher_input (dispatcher.c:135)
> ==26215==by 0x4E599BB: pn_input_read_amqp (transport.c:2524)
> ==26215==by 0x4E59A89: transport_consume (transport.c:1800)
> ==26215==by 0x4E5D115: pn_transport_process (transport.c:2909)
> ==26215==by 0x404EBB: on_read (libuv_proactor.c:511)
> ==26215==by 0x509A2FC: ??? (in /usr/lib/libuv.so.1.0.0)
> ==26215==by 0x509AC0B: ??? (in /usr/lib/libuv.so.1.0.0)
> ==26215==by 0x509F937: uv__io_poll (in /usr/lib/libuv.so.1.0.0)
> ==26215==by 0x50912B3: uv_run (in /usr/lib/libuv.so.1.0.0)
> ==26215==  Address 0x69c28d1 is 0 bytes after a block of size 1 alloc'd
> ==26215==at 0x4C2AB8D: malloc (in 
> 

[jira] [Updated] (PROTON-1359) heap-buffer-overflow in pn_decoder_readf32 when invoking pn_message_decode

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1359:

Fix Version/s: 0.17.0

> heap-buffer-overflow in pn_decoder_readf32 when invoking pn_message_decode
> --
>
> Key: PROTON-1359
> URL: https://issues.apache.org/jira/browse/PROTON-1359
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.16.0
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Fix For: 0.17.0
>
> Attachments: core.322, 
> crafted_from_minimized-from-ac1dd1edf2357b0e4782088fa2bf80fdde832a43, 
> minimized-from-ac1dd1edf2357b0e4782088fa2bf80fdde832a43
>
>
> {noformat}
> $ nc -l 5672 < 
> crafted_from_minimized-from-ac1dd1edf2357b0e4782088fa2bf80fdde832a43
> $ ./libuv_receive -a 127.0.0.1:5672/jms.queue.example 
> Segmentation fault (core dumped)
> (gdb) thread apply all bt
> 
> #5209 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5210 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972817 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5211 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5212 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972897 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5213 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5214 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972917 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5215 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5216 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972997 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5217 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5218 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972a17 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5219 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5220 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972a97 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5221 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5222 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972b17 "\377\200\304\t\002")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5223 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5224 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972b97 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5225 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5226 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972c17 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5227 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5228 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972c97 "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5229 0x7f36d947a651 in pni_decoder_single (decoder=0x209c970, 
> data=0x209c480) at 
> /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:474
> #5230 0x7f36d947a786 in pni_decoder_decode_type (decoder=0x209c970, 
> data=0x209c480, code=0x7ffd99972e0d "")
>   at /home/jdanek/Bin/qpid-proton/proton-c/src/core/decoder.c:458
> #5231 0x7f36d947b2ac in pni_decoder_decode_value (decoder=0x209c970, 
> 

[jira] [Commented] (QPIDJMS-207) Implement the JMS 2.0 API

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15736568#comment-15736568
 ] 

ASF subversion and git services commented on QPIDJMS-207:
-

Commit b35e2f50450aeab3ed001a43f69b932d91a2e295 in qpid-jms's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b35e2f5 ]

QPIDJMS-207 Fix test failure

> Implement the JMS 2.0 API
> -
>
> Key: QPIDJMS-207
> URL: https://issues.apache.org/jira/browse/QPIDJMS-207
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Affects Versions: 0.11.0
>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] [Updated] (PROTON-1312) BlockingConnection leaks Proton-C memory

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1312:

Assignee: Cliff Jansen

> BlockingConnection leaks Proton-C memory
> 
>
> Key: PROTON-1312
> URL: https://issues.apache.org/jira/browse/PROTON-1312
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9, 0.15.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>  Labels: leak, reproducer
> Fix For: 0.17.0
>
> Attachments: ml8.py
>
>
> The attached program leaks the underlying connection (the C proton
> object) associated with the BlockingConnection on each loop iteration
> on proton 0.9 as used by Satellite.  Without the receiver, it cleans
> up fine.
> On master, the program leaks both the reactor and the connection
> associated with the BlockingConnection for each loop.  The receiver
> creation can be commented out and it still leaks both objects.
> Other objects may leak too (presumably session), but I have not
> examined further.



--
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-574) Restore Qpid dispatch docs into man and book folders

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15736325#comment-15736325
 ] 

ASF subversion and git services commented on DISPATCH-574:
--

Commit e7bcfea402852524ad4ef3c50795fb7cbecebf67 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e7bcfea ]

DISPATCH-574 - Minor fix to make the build work with older cmake version


> Restore Qpid dispatch docs into man and book folders
> 
>
> Key: DISPATCH-574
> URL: https://issues.apache.org/jira/browse/DISPATCH-574
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 0.8.0
>
>
> After moving to asciidoc, the html files are not in their respective man  and 
> book folders. The qpid-site scripts expect them to be in the respective 
> folders.



--
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-7423) [0-8...0-91] Chunk message content that exceeds the capacity of a single frame into multiple frames

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7423:
--
Fix Version/s: qpid-python-1.36.0

> [0-8...0-91] Chunk message content that exceeds the capacity of a single 
> frame into multiple frames
> ---
>
> Key: QPID-7423
> URL: https://issues.apache.org/jira/browse/QPID-7423
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-python-1.36.0
>
>
> The legacy Python client [0-8..0-91] currently will send an oversize message 
> content frame if the application supplied content exceeds the configured 
> frame size.  



--
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] [Closed] (QPID-7428) [Python Client 0-8..0-91] Legacy Python client leaks threads when connection is closed from broker side

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-7428.
-

> [Python Client 0-8..0-91] Legacy Python client leaks threads when connection 
> is closed from broker side
> ---
>
> Key: QPID-7428
> URL: https://issues.apache.org/jira/browse/QPID-7428
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: 0.32, qpid-python-1.35.0
>Reporter: Alex Rudyy
>
> Python client does not stop properly its threads when connection is closed 
> from broker side. As result, client application can leak threads and 
> eventually ran out of threads.
> It seems that writer thread from Peer is blocked on outgoing queue and never 
> exits



--
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] [Closed] (QPID-6191) Unable to communicate to Windows Azure using qpid messaging

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6191.
-

> Unable to communicate to Windows Azure using qpid messaging
> ---
>
> Key: QPID-6191
> URL: https://issues.apache.org/jira/browse/QPID-6191
> Project: Qpid
>  Issue Type: Bug
>  Components: Qpid Examples
>Reporter: Rajkumar
>
> import sys
> from qpid.messaging import *
> if len(sys.argv)<2:
>   broker =  "***namespace***.servicebus.windows.net"
> else:
>   broker = sys.argv[1]
> if len(sys.argv)<3: 
>   address = "**queuename**" 
> else:
>   address = sys.argv[2]
> connection = Connection(broker)
> connection.username = "owner"
> connection.password = "passwordkey"
> connection.protocol = "amqp1.0"
> try:
>   connection.open()
>   session = connection.session()
>   sender = session.sender(address)
>   receiver = session.receiver(address)
>   sender.send(Message("Hello world!"));
>   message = receiver.fetch()
>   print message.content
>   session.acknowledge()
> except MessagingError,m:
>   print m
> connection.close()
> I have tried the above code to send message to Azure queue. But I got 
> "client: 0-10, server: 0-0" when open a connection. Please anyone help me.



--
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] [Closed] (QPID-2699) Interop coordinator should not depend on qpid broker libraries.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-2699.
-

> Interop coordinator should not depend on qpid broker libraries.
> ---
>
> Key: QPID-2699
> URL: https://issues.apache.org/jira/browse/QPID-2699
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: 0.6, 0.7
>Reporter: Sorin Suciu
>Assignee: Sorin Suciu
>Priority: Minor
>
> The coordinator currently depends on QpidBrokerTestCase (needs the 
> getConnection() call). As the coordinator acts actually as a client, only the 
> client and common library should be a dependency. 



--
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] [Closed] (QPID-2821) Replace the o.a.q.transport.Future with java.util.concurrent.Future

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-2821.
-

> Replace the o.a.q.transport.Future with java.util.concurrent.Future
> ---
>
> Key: QPID-2821
> URL: https://issues.apache.org/jira/browse/QPID-2821
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: 0.7
>Reporter: Sorin Suciu
>Assignee: Sorin Suciu
>Priority: Minor
>
> The o.a.q.transport.Future seems to be similar with 
> java.util.concurrent.Future with the exception that it does not implement the 
> isCancelled() and get(long,TimeUnit) methods. I think it would be useful if 
> we align to the jdk concurrent classes rather then using our custom ones. 



--
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-212) Calling close() on a connection or session, any pending receive() should retrun null

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-212:
-
Component/s: Java Client

> Calling close() on a connection or session, any pending receive() should 
> retrun null
> 
>
> Key: QPID-212
> URL: https://issues.apache.org/jira/browse/QPID-212
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Attachments: QPID-212.patch
>
>
> Currently the application will hang indefinitely on the blocking receive() 
> call.  The spec says it should return null if the connection is closed



--
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-5746) [Java Broker] Split attributes annotations into DervicedAttributes and ManagedAttributes, allow derived attributes to be persisted

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5746:
--
Component/s: Java Broker

> [Java Broker] Split attributes annotations into DervicedAttributes and 
> ManagedAttributes, allow derived attributes to be persisted
> --
>
> Key: QPID-5746
> URL: https://issues.apache.org/jira/browse/QPID-5746
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Split attributes annotations into DervicedAttributes and ManagedAttributes, 
> allow derived attributes to be persisted.
> Only store attributes that are marked as persistable, not everything that 
> happens to be in the attribute map.



--
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] [Closed] (QPID-1686) Configuration Update removes ability ot have multiple distinct InVM brokers.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-1686.
-

> Configuration Update removes ability ot have multiple distinct InVM brokers.
> 
>
> Key: QPID-1686
> URL: https://issues.apache.org/jira/browse/QPID-1686
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Martin Ritchie
>Priority: Minor
>
> Before the change creating a new ApplicationRegistry with an id would result 
> in a distinct AR.
> Now the code is littered with ApplicationRegistry.getInstance() calls which 
> returns the AR with id 1.
> This prevents us having InVM brokers with their own config.
> The problem can be removed if the new Configuration objects form a tree so 
> you can do:
> QueueConfig.getVHostConfig().getServerConfig() 
> This could then replace the short cut of using AR.getInstance().



--
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-1686) Configuration Update removes ability ot have multiple distinct InVM brokers.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-1686:
--
Component/s: Java Broker

> Configuration Update removes ability ot have multiple distinct InVM brokers.
> 
>
> Key: QPID-1686
> URL: https://issues.apache.org/jira/browse/QPID-1686
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Martin Ritchie
>Priority: Minor
>
> Before the change creating a new ApplicationRegistry with an id would result 
> in a distinct AR.
> Now the code is littered with ApplicationRegistry.getInstance() calls which 
> returns the AR with id 1.
> This prevents us having InVM brokers with their own config.
> The problem can be removed if the new Configuration objects form a tree so 
> you can do:
> QueueConfig.getVHostConfig().getServerConfig() 
> This could then replace the short cut of using AR.getInstance().



--
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] [Closed] (QPID-1393) 5 instance of JCAProvider need to be consolidated

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-1393.
-

> 5 instance of JCAProvider need to be consolidated
> -
>
> Key: QPID-1393
> URL: https://issues.apache.org/jira/browse/QPID-1393
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: M3
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
>
> Summary:
> Currently we have 5 different copies of JCAProvider which could be refactored 
> in to a single common implementation.



--
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] [Closed] (QPID-1193) Bind arguments must be stored with binding in DerbyStore

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-1193.
-

> Bind arguments must be stored with binding in DerbyStore
> 
>
> Key: QPID-1193
> URL: https://issues.apache.org/jira/browse/QPID-1193
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
>  Labels: derbystore
>
> Summary:
> To ensure that the binding can be correctly created on recovery the arguments 
> provided in the Bind method must be recorded in the Store.
> This is part of QPID-1191 to fully implement JMS Topics with Selectors.



--
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-7087) [Java Broker, Web Management Console] The Web UI should have a Qpid favicon

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7087:
--
Component/s: Java Broker

> [Java Broker, Web Management Console] The Web UI should have a Qpid favicon
> ---
>
> Key: QPID-7087
> URL: https://issues.apache.org/jira/browse/QPID-7087
> Project: Qpid
>  Issue Type: Wish
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Minor
> Attachments: qpid-favicon.png
>
>
> Currently we do not supply a [favicon|https://en.wikipedia.org/wiki/Favicon]. 
> Instead Jetty inserts its own favicon.
> We should supply our own. I would suggest the Qpid "Q" with the feather.



--
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-1427) [Java] QueueBrowserDupsOKTest Failure

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-1427:
--
Component/s: Java Tests

> [Java] QueueBrowserDupsOKTest Failure
> -
>
> Key: QPID-1427
> URL: https://issues.apache.org/jira/browse/QPID-1427
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Affects Versions: M3, M4
>Reporter: Marnie McCormack
>Assignee: Martin Ritchie
>Priority: Minor
> Attachments: 
> TEST-org.apache.qpid.test.client.QueueBrowserClientAckTest.testQueueBrowserMsgsRemainOnQueue.out
>
>
> Test: testQueueBrowserMsgsRemainOnQueue
> Class:org.apache.qpid.test.client.QueueBrowserDupsOkTest
>   
> junit.framework.AssertionFailedError: Message 0 not retrieved from queue  
> at 
> org.apache.qpid.test.client.QueueBrowserAutoAckTest.validate(QueueBrowserAutoAckTest.java:334)
>   
> at 
> org.apache.qpid.test.client.QueueBrowserAutoAckTest.testQueueBrowserMsgsRemainOnQueue(QueueBrowserAutoAckTest.java:379)
>   
> at org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:186)  
> at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:220)
>   



--
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] [Closed] (QPID-213) Improvements for management eclipse-plugin GUI

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-213.


> Improvements for management eclipse-plugin GUI
> --
>
> Key: QPID-213
> URL: https://issues.apache.org/jira/browse/QPID-213
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Bhupendra Bhardwaj
>Assignee: Bhupendra Bhardwaj
>
> Following improvements are to be done in the management gui-
> - remove space between refresh button and operation name (eg. bindings 
> operaion for exchanges)
> - the background for box dispalying results should be white(same as operaion 
> tab background) (eg. bindings result)
> - When a type (eg  Exchange) is selected, the MBeanView should show all the 
> mbeans under that type
> - All MBeans should not be listed on the navigation view by default. those 
> should be added from right hand side view, where all mbeans under one type(eg 
> Exchange) are listed.
> - Feature to sort Queues according to queue depth.
> - Features to Sort Queues according to the no of consumers
> - The combo boxes for mbean operations (eg. delete queue) can be list, so it 
> is easy to select an item. In the example of deleteQueue, the queue selection 
> will be easier



--
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] [Closed] (QPID-937) Typo in getting-started page of the site

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-937.


> Typo in getting-started page of the site
> 
>
> Key: QPID-937
> URL: https://issues.apache.org/jira/browse/QPID-937
> Project: Qpid
>  Issue Type: Bug
>Reporter: Suran Jayathilaka
>Assignee: Aidan Skinner
>Priority: Trivial
>
> In http://cwiki.apache.org/qpid/getting-started-guide.html, in the 
> "Configuration" section, the line says
> "persistent_confg.xml - when you want to use any persistent messages with the 
> Qpid broker (currently with BDB)"
> It should say
> "persistent_config.xml - when you want to use any persistent messages with 
> the Qpid broker (currently with BDB)".



--
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] [Closed] (QPID-1284) QMan : Qpid JMX Management Bridge

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-1284.
-

> QMan : Qpid JMX Management Bridge
> -
>
> Key: QPID-1284
> URL: https://issues.apache.org/jira/browse/QPID-1284
> Project: Qpid
>  Issue Type: New Feature
>Affects Versions: M3
> Environment: J2SE 5, any OS that is supporting Java
>Reporter: Andrea Gazzarini
>Assignee: Arnaud Simon
> Attachments: DomainModel.jpg, Invokes an operation.jpg, QMan.jar, 
> QpidClass.jpg, actors.jpg, class_definition_building.jpg, 
> commons-pool-1.4.jar, configuration_domain_model.jpg, 
> estabilish_initial_connection.jpg, management_message.jpg, 
> message_processing.jpg, qman_14102008_latest.patch, qman_patch, 
> qman_patch_08102008, qman_patch_14102008, qman_predefined_handlers_patch, 
> qman_test_cases_patch, qman_test_cases_patch_08102008, 
> qpid_patch_under_management_folder_12102008, use_cases.jpg
>
>
> QMan is an application used for exposing via JMX the management domain model 
> of one or more remote brokers.
> Capabilities (the list is not complete) : 
> - Operates from a formally defined management schema;
> - Uses the AMQP protocol and its type system for communicating with remote 
> brokers;
> - Exposes via JMX the remote broker domain model: that means for each 
> connected broker QMan lets you see its domain model entities according to 
> their schema (attribute, methods, statistics and events). In addition, lets 
> you invoke operations on those entities.  
> - Multi broker management; 
> - It doesn't have prior knowledge of the management model of the system under 
> management. no definition is hard-coded and entity definitions (schema) are 
> requested and built "on demand";
> - Namespace separation between brokers : each connected broker can have a 
> different schema. 
> - JMX interface : QMan is itself a Management Bean and using JMX it exposes 
> its public interface (for example, to connect with a new broker). So at the 
> end it should be exposed via WS-DM, SMTP, RMI, 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] [Closed] (QPID-1522) Refactor Command classes so that more common code is shared.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-1522.
-

> Refactor Command classes so that more common code is shared. 
> -
>
> Key: QPID-1522
> URL: https://issues.apache.org/jira/browse/QPID-1522
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: M4
>Reporter: Aidan Skinner
>Assignee: Rob Godfrey
> Attachments: 
> 0001-QPID-1522-Raname-Command-class-to-CommandImpl-and-m.patch, 
> 0002-QPID-1522-Move-common-code-up-to-CommandImpl.-Renam.patch, 
> 0003-QPID-1522-Fix-spelling-error-in-classname.patch, 
> 0004-QPID-1522-Move-command-line-constants-to-individual.patch
>
>
> The Command subclasses have some duplicate code which could be shared. 



--
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-2740) QpidRollingFileAppender does not use backupFilesToPath when compression is not enabled.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-2740:
--
Component/s: Java Broker

> QpidRollingFileAppender does not use backupFilesToPath when compression is 
> not enabled.
> ---
>
> Key: QPID-2740
> URL: https://issues.apache.org/jira/browse/QPID-2740
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: M4, 0.5, 0.6
>Reporter: Martin Ritchie
>
> The original augmentation of the log4j RollingAppender to the ability to 
> create a compress backup of files.
> Some users are now wanting to simply backup uncompressed files to the 
> 'backupFilesToPath'.
> Currently this property is ignored unless the CompressBackupFiles is set to 
> true.
> We should change the backup functionality to be based on the setting of 
> 'backupFilesToPath' irrespective of the CompressBackupFiles



--
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] [Closed] (QPID-4571) Qpid client should provide a PooledConnectionFactory rather like that of ActiveMQ

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-4571.
-

> Qpid client should provide a PooledConnectionFactory rather like that of 
> ActiveMQ
> -
>
> Key: QPID-4571
> URL: https://issues.apache.org/jira/browse/QPID-4571
> Project: Qpid
>  Issue Type: Wish
>Reporter: Keith Wall
>  Labels: spring
>
> For better integration with frameworks such as Spring, the Qpid Client should 
> provide a pooled connection factory rather like that provided by ActiveMQ:
> http://activemq.apache.org/spring-support.html
> Whilst such as factory is beyond that required by JMS, this would make it 
> easier for Qpid/Spring users to scale up the number of connections between an 
> application and a Broker in a convenient manner. 



--
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-4412) [AMQP 1-0 Java Common] ReceivingLinkEndpoint.isDrained result is invalid

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-4412:
--
Component/s: Java Common

> [AMQP 1-0 Java Common] ReceivingLinkEndpoint.isDrained result is invalid
> 
>
> Key: QPID-4412
> URL: https://issues.apache.org/jira/browse/QPID-4412
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Common
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
> Attachments: QPID-4412-v2.patch
>
>
> the delivery count was not being updated when a Flow was received.



--
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-1528) Get/Set attributes on objects

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-1528:
--
Component/s: Java Tools

> Get/Set attributes on objects
> -
>
> Key: QPID-1528
> URL: https://issues.apache.org/jira/browse/QPID-1528
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Tools
>Reporter: Aidan Skinner
>Assignee: Aidan Skinner
>
> It would be useful to be able to get and set attributes on objects via the 
> CLI such as MaximumMessageAge 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] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5614:
--
Component/s: Java Broker

> Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578
> ---
>
> Key: QPID-5614
> URL: https://issues.apache.org/jira/browse/QPID-5614
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Fraser Adams
>
> QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
> unfortunately those changes trashed the QMF2 Management Plugin.
> This Jira relates to the work to fix the QMF2 Management Plugin.



--
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-755) Durable subscription test does not test durability.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-755:
-
Component/s: Java Tests

> Durable subscription test does not test durability.
> ---
>
> Key: QPID-755
> URL: https://issues.apache.org/jira/browse/QPID-755
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Reporter: Rupert Smith
>
> The test sets up subscriptions 1 and 2, 2 is durable, later it kills 2 and 
> creates 3, also durable.
> open 1
> open 2
> send A.
> check 1 got it.
> check 2 got it
> close 2.
> open 3.
> send B.
> check 1 got it.
> check 2 got it.
> But, 3 should not have been open until after B was sent, in order to check 
> that 3 gets messages from the durable subscription that it missed, while no 
> consumer was connected to the subscription.



--
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-6727) Remove sendBufferSize/receiveBufferSize from AmqpPort and make max framesize/sendBufferSize/receiveBufferSize share a single source

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6727:
--
Component/s: Java Broker

> Remove sendBufferSize/receiveBufferSize from AmqpPort and make max 
> framesize/sendBufferSize/receiveBufferSize share a single source
> ---
>
> Key: QPID-6727
> URL: https://issues.apache.org/jira/browse/QPID-6727
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Attachments: 
> 0001-QPID-6727-Java-Broker-use-unified-network-buffer-siz.patch
>
>
> Currently the TCP/IP buffer sizes (sendBufferSize/receiveBufferSize) are 
> attributes of AmpqPort.  For the new memory model, supporting different ports 
> using different receive buffers would be problematic and cause inefficient 
> use of direct memory.  Similarly clients using framesizes where the framesize 
> !=buffer size will be inefficient.
> # Remove sendBufferSize/receiveBufferSize from the Port.
> # Make max frame size and sendBufferSize/receiveBufferSize share a single 
> source which should be a context variable belonging to the Broker. Minimum 
> size must be no smaller than SSL netbuffer size
> # The context variable should be evaluated only once at Broker startup.
> # Upgraders should remove the attribute from AmqpPorts



--
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-1915) CommitRollbackTest fails when run with bdb store loaded

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-1915:
--
Component/s: Java Tests

> CommitRollbackTest fails when run with bdb store loaded
> ---
>
> Key: QPID-1915
> URL: https://issues.apache.org/jira/browse/QPID-1915
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Reporter: Aidan Skinner
> Attachments: 
> TEST-org.apache.qpid.test.unit.transacted.CommitRollbackTest.testCommitWhithinOnMessage.out
>
>
> TestName: testCommitWhithinOnMessage Duration: 37.755
> Did not received message
> junit.framework.AssertionFailedError: Did not received message
>   at 
> org.apache.qpid.test.unit.transacted.CommitRollbackTest.testCommitWhithinOnMessage(CommitRollbackTest.java:526)
>   at 
> org.apache.qpid.test.utils.QpidTestCase.runBare(QpidTestCase.java:204)
>   at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:249)



--
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] [Closed] (QPID-998) Prevent warnings about missing bin / etc directories

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-998.


> Prevent warnings about missing bin / etc directories
> 
>
> Key: QPID-998
> URL: https://issues.apache.org/jira/browse/QPID-998
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
>  Labels: ant_build_system
>   Original Estimate: 0.25h
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Summary:
> Would be good to have a clean build with ant where no warnings were shown.
> Currently we have a few modules that show a warning as they have no bin or 
> etc directory to copy to the build tree.
> This is due to the generic nature of our build system but using a condition 
> check to see if the directories exist we can prevent the error.



--
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] [Closed] (QPID-924) Ruby test.rb use of '0.0.0.0' for localhost doesn't work under cygwin

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-924.


> Ruby test.rb use of '0.0.0.0' for localhost doesn't work under cygwin
> -
>
> Key: QPID-924
> URL: https://issues.apache.org/jira/browse/QPID-924
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: M2.1
>Reporter: Martin Ritchie
>  Labels: old_ruby_test_suite_component
>
> Summary:
> The use of '0.0.0.0' in the test.rb file for localhost does not work under 
> cygwin and windows. 
> Suggest changing it to 'localhost'



--
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-3672) Occasional NPE from Qpid Management Console when connecting to server

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-3672:
--
Component/s: Java Management : JMX Console

> Occasional NPE from Qpid Management Console when connecting to server
> -
>
> Key: QPID-3672
> URL: https://issues.apache.org/jira/browse/QPID-3672
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Management : JMX Console
>Affects Versions: 0.15
>Reporter: Keith Wall
>Assignee: Keith Wall
>  Labels: jmx_interface
> Attachments: 
> 0001-QPID-3672-Occasional-NPE-from-Qpid-Management-Consol.patch
>
>
> We are seeing the follow NPE whilst connecting the Qpid Management Console to 
> the Broker.  The NPE seems to be non-deterministic.
> {code}
> java.lang.NullPointerException
> at 
> org.apache.qpid.management.ui.views.NavigationView.doesMBeanNodeAlreadyExist(NavigationView.java:584)
> at 
> org.apache.qpid.management.ui.views.NavigationView.addManagedBean(NavigationView.java:685)
> at 
> org.apache.qpid.management.ui.views.NavigationView.populateServer(NavigationView.java:510)
> at 
> org.apache.qpid.management.ui.views.NavigationView.addNewServer(NavigationView.java:314)
> at 
> org.apache.qpid.management.ui.actions.AddServer.run(AddServer.java:72)
> at 
> org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251)
> at 
> org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:229)
> at 
> org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:583)
> at 
> org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:500)
> at 
> org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java:452)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
> at 
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
> at 
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
> at 
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
> at 
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.apache.qpid.management.ui.Application.run(Application.java:46)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574)
> at 
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:195)
> at 
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at 
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at 
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
> at 
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
> {code}
> Investigation has shown that the NPE is caused between an interaction between 
> the ShutdownPlugin and the NavigationView#addManagedBean method of the UI.
> As the Shutdown Plugin has no name (only a type), if it is processed by the 
> addManagedBean algorithm *first* all is well.  However if it is processed 
> *after* another MBean the NPE occurs.  The non deterministic nature of the 

[jira] [Closed] (QPID-3670) Add new build target to allow the Cobertura jar files to be downloaded automatically if not already present.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-3670.
-

> Add new build target to allow the Cobertura jar files to be downloaded 
> automatically if not already present.
> 
>
> Key: QPID-3670
> URL: https://issues.apache.org/jira/browse/QPID-3670
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: 0.12
>Reporter: Andrew MacBean
>Assignee: Robbie Gemmell
>  Labels: ant_build_system
> Attachments: 
> 0001-QPID-3670-Add-new-build-target-to-allow-the-Cobertur.patch
>
>
> Add a build target to allow the Cobertura jar files to be downloaded 
> automatically if not already present.
> This will allow us to get Jenkins to generate Cobertura coverage reports from 
> builds and allow users to produce local reports easily.



--
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-5081) [Java Broker] Refactor creation of Queue within the broker

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-5081:
--
Component/s: Java Broker

> [Java Broker] Refactor creation of Queue within the broker
> --
>
> Key: QPID-5081
> URL: https://issues.apache.org/jira/browse/QPID-5081
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>
> 1. Modify the VirtualHost interface to hide the QueueRegistry, and route all 
> queue creation through the Virtual Host (cf QPID-4979 for Exchanges)
> 2. Modify the Queue Creation arguments to use the model argument names, 
> rather than the names used on the wire in AMQP commands (and build a utility 
> class for converting between these) 



--
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-6180) Cannot create BDB HA group on Windows development environment due to node folder not being reported as writable by Files.isWritable(Path)

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-6180:
--
Component/s: Java Broker

> Cannot create BDB HA group on Windows development environment due to node 
> folder not being reported as writable by Files.isWritable(Path)
> -
>
> Key: QPID-6180
> URL: https://issues.apache.org/jira/browse/QPID-6180
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Andrew MacBean
>Assignee: Alex Rudyy
>
> Cannot create BDB HA group on Windows development environment due to node 
> folder not being reported as writable by Files.isWritable(Path).
> The call to Files.isWritable(storePath.toPath()) in 
> BDBHAVirtualHostNodeImpl#validateStorePath() returns false incorrectly when 
> using earlier version of the Java 1.7 JDK 
> (http://bugs.java.com/view_bug.do?bug_id=7190897). This can worked around 
> using the File#canWrite() method instead.



--
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-1564) CLI code has duplicate headers, does not follow coding standards.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-1564:
--
Component/s: Java Tools

> CLI code has duplicate headers, does not follow coding standards. 
> --
>
> Key: QPID-1564
> URL: https://issues.apache.org/jira/browse/QPID-1564
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tools
>Reporter: Aidan Skinner
>Assignee: Rob Godfrey
>
> The qpid-cli code has duplicate ASL headers in some files and does not follow 
> the qpid coding standards. 



--
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-2576) Standardise queue Ownership across protocols

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-2576:
--
Component/s: Java Broker

> Standardise queue Ownership across protocols
> 
>
> Key: QPID-2576
> URL: https://issues.apache.org/jira/browse/QPID-2576
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
>
> Currently the broker does not have a consistent view of who the queue Owner 
> is. The 0-8/0-9/0-91 code path uses client id.
> The 0-10 code path uses the authenticated user name.
> In a number of locations such as:
>  DerbyMessageStore uses the authenticated Principal name.
>  QueueDeclareHandler compares principal name against getOwner for exclusive 
> queue checks. 
>  (This will only work if a 0-10 client created the queue as it will set the 
> owner name to the principal name, see sub jira on this issue)
> From the JMS Spec 4.3.2
> The purpose of the client identifier is to associate a connection and its 
> objects
> with a state maintained on behalf of the client by a provider. By definition, 
> the
> client state identified by a client identifier can be `in use' by only one 
> client at
> a time. A JMS provider must prevent concurrently executing clients from using
> it.
> Which suggests that it could be used to perform exclusive queue detection 
> rather than the authenticated user that could log in more than once. This 
> will need more discussion on dev.
> First step is to ensure the code all uses getOwner even if the 0-10 version 
> currently sets that to the authenticated Principal.



--
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] [Closed] (QPID-2160) msTool.sh does not cleanly exit with quit command.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-2160.
-

> msTool.sh does not cleanly exit with quit command.
> --
>
> Key: QPID-2160
> URL: https://issues.apache.org/jira/browse/QPID-2160
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.5, 0.6
>Reporter: Martin Ritchie
>
> When exiting from the msTool.sh the process hangs: 
> bdb$ quit
> ...exiting
> To get the process to fully exit you must press 'ctrl-c' 



--
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-2606) Clarify/identify where ACL permission should be applied in the broker

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-2606:
--
Component/s: Java Broker

> Clarify/identify where ACL permission should be applied in the broker 
> --
>
> Key: QPID-2606
> URL: https://issues.apache.org/jira/browse/QPID-2606
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Broker
>Reporter: Andrew Kennedy
>Assignee: Robbie Gemmell
> Attachments: 0003-QPID-2606-Access-Control-Modifications.patch
>
>




--
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] [Closed] (QPID-2047) Remove a few IDE complaints

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-2047.
-

> Remove a few IDE complaints
> ---
>
> Key: QPID-2047
> URL: https://issues.apache.org/jira/browse/QPID-2047
> Project: Qpid
>  Issue Type: Task
>Reporter: Martin Ritchie
>
> Summary:
> Idea complains about two issues with the command objects.
> 1) They call the method ObjectNames in class ObjectNames. This looks like a 
> constructor but it is not.
>  - Replace method with better constructor use.
> 2) AllObjects returnedObjects removes the generic discriminator.
>  - the return should be Set not just 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] [Updated] (QPID-2739) QpidRollingFileAppender does not delete backup files.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-2739:
--
Component/s: Java Broker

> QpidRollingFileAppender does not delete backup files.
> -
>
> Key: QPID-2739
> URL: https://issues.apache.org/jira/browse/QPID-2739
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: M4, 0.5, 0.6
>Reporter: Martin Ritchie
>
> Currently the QpidRollingFileAppender behaves like the log4j 
> RollingFileAppender wrt maintaining a maximum number of backup files. 
> When a file is to be deleted the file with relative path is provided to the 
> delete method. Trouble is we have augmented RollingFileAppender to provide a 
> backup loaction. This means that the deleteFile method fails to delete the 
> file as the main Appender code does not know about the backup location.
> Augmenting the delete method to change the path would be in line with the 
> addition to add the compression file extension that is already performed here.



--
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-4647) Broker allows the creation of duplicate queue entries on a single queue which then fail on-dequeue.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-4647:
--
Component/s: Java Broker

> Broker allows the creation of duplicate queue entries on a single queue which 
> then fail on-dequeue.
> ---
>
> Key: QPID-4647
> URL: https://issues.apache.org/jira/browse/QPID-4647
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.21
>Reporter: Keith Wall
>
> Using the copyMessage function, it is possible to cause a single message to 
> appear _twice_ on a single queue. When a consumer consumes the duplicate and 
> tries to acknowledge the duplicate, the Broker produces the following error. 
> It is also possible to create the same situation using certain dead-letter 
> arrangements.
> org.apache.qpid.AMQStoreException: Unable to find message with id 1 on queue 
> dest with id 1ad9e427-b87e-3702-8ea3-0816a10d60ba [error code 541: internal 
> error] at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.dequeueMessage(AbstractBDBMessageStore.java:948)
>  at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$BDBTransaction.dequeueMessage(AbstractBDBMessageStore.java:1643)
>  at 
> org.apache.qpid.server.txn.LocalTransaction.dequeue(LocalTransaction.java:142)
>  at org.apache.qpid.server.AMQChannel.acknowledgeMessage(AMQChannel.java:847) 
> at 
> org.apache.qpid.server.handler.BasicAckMethodHandler.methodReceived(BasicAckMethodHandler.java:65)
>  at 
> org.apache.qpid.server.handler.ServerMethodDispatcherImpl.dispatchBasicAck(ServerMethodDispatcherImpl.java:133)
>  at 
> org.apache.qpid.framing.amqp_0_9.BasicAckBodyImpl.execute(BasicAckBodyImpl.java:123)
>  at 
> org.apache.qpid.server.state.AMQStateManager.methodReceived(AMQStateManager.java:120)
>  at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.methodFrameReceived(AMQProtocolEngine.java:454)
>  at 
> org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:97) 
> at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.frameReceived(AMQProtocolEngine.java:338)
>  at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.dataBlockReceived(AMQProtocolEngine.java:283)
>  at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:242)
>  at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
>  at 
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
>  at 
> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
>  at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161) 
> at java.lang.Thread.run(Thread.java:662) 



--
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] [Closed] (QPID-3326) Modify ant build scripts to work with Maven

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-3326.
-

> Modify ant build scripts to work with Maven
> ---
>
> Key: QPID-3326
> URL: https://issues.apache.org/jira/browse/QPID-3326
> Project: Qpid
>  Issue Type: Bug
>  Components: a
>Reporter: Danushka Menikkumbura
>Assignee: Robbie Gemmell
> Attachments: QPID-3326.patch
>
>




--
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-3468) [Java Tests] Exclude QueueBrowser* failover tests from 0-10 as they should fail (and sometimes do)

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-3468:
--
Component/s: Java Tests

> [Java Tests] Exclude QueueBrowser* failover tests from 0-10 as they should 
> fail (and sometimes do)
> --
>
> Key: QPID-3468
> URL: https://issues.apache.org/jira/browse/QPID-3468
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> The QueueBrowser*Tests attempt to test failover of QueueBrowsers.  These 
> tests expect that on failover QueueBrowsing will resume (potentially from the 
> start of the queue).  This is not how failover has been implemented in the 
> 0-10 library and so these tests should be excluded.



--
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-3326) Modify ant build scripts to work with Maven

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-3326:
--
Component/s: a

> Modify ant build scripts to work with Maven
> ---
>
> Key: QPID-3326
> URL: https://issues.apache.org/jira/browse/QPID-3326
> Project: Qpid
>  Issue Type: Bug
>  Components: a
>Reporter: Danushka Menikkumbura
>Assignee: Robbie Gemmell
> Attachments: QPID-3326.patch
>
>




--
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] [Closed] (QPID-2241) Web site logo - make feather align with Apache logo

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-2241.
-

> Web site logo - make feather align with Apache logo
> ---
>
> Key: QPID-2241
> URL: https://issues.apache.org/jira/browse/QPID-2241
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Jonathan Robie
> Attachments: header3.png
>
>
> I think the feather on the Qpid logo should align with the Apache logo. 
> Here's an attempt to make it do so.



--
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] [Closed] (QPID-5553) cpp build fails on ha_test_max_queues.cpp

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-5553.
-

> cpp build fails on ha_test_max_queues.cpp
> -
>
> Key: QPID-5553
> URL: https://issues.apache.org/jira/browse/QPID-5553
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Priority: Blocker
>
> After an svn update to r1568639 I tried to build qpid cpp
> I did
> cmake -DCMAKE_BUILD_TYPE=Release ..
> and also, just to check
> cmake ..
> both fail for me using gcc 4.6.1
> I got as far as below - seems to be a problem with ha_test_max_queues.cpp
> Scanning dependencies of target ha_test_max_queues
> [ 80%] Building CXX object 
> src/tests/CMakeFiles/ha_test_max_queues.dir/ha_test_max_queues.cpp.o
> /home/fadams/qpid/qpid-trunk/qpid/cpp/src/tests/ha_test_max_queues.cpp:32:5: 
> error: unused parameter ‘argc’ [-Werror=unused-parameter]
> cc1plus: all warnings being treated as errors
> make[2]: *** 
> [src/tests/CMakeFiles/ha_test_max_queues.dir/ha_test_max_queues.cpp.o] Error 1
> make[1]: *** [src/tests/CMakeFiles/ha_test_max_queues.dir/all] Error 2
> make: *** [all] Error 2



--
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] [Closed] (QPID-4646) Makefile.PL should not be touched by configure.ac

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-4646.
-

> Makefile.PL should not be touched by configure.ac
> -
>
> Key: QPID-4646
> URL: https://issues.apache.org/jira/browse/QPID-4646
> Project: Qpid
>  Issue Type: Bug
>Reporter: Darryl L. Pierce
>Assignee: Darryl L. Pierce
>
> Previously Makefile.PL was generated as a part of the build. The file is now 
> no longer generated, but was still being touched by this file. The file 
> should not be touched as a part of the autotools build.



--
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] [Closed] (QPID-6499) QPID C++ Broker - Windows User Authentication

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6499.
-

> QPID C++ Broker - Windows User Authentication
> -
>
> Key: QPID-6499
> URL: https://issues.apache.org/jira/browse/QPID-6499
> Project: Qpid
>  Issue Type: Bug
> Environment: Windows 8.1, QPID 0.32, Proton 0.9
>Reporter: Nathan Lusher
>Priority: Blocker
>
> Hi,
> I have a C# .NET client happily talking to a QPID broker. I now want to 
> introduce authentication and pass through the username and password as 
> connection options.
> I am able to run the QPID broker with an acl file with the following line:
> acl allow guest all all
> But cannot send a message when I pass {username:guest} {password:guest} in 
> the connection options string.
> I have a Windows user named 'Guest' with a password of 'guest', but that 
> doesn't seem to make any difference.
> I can connect fine when I set auth=no or change the line in the acl file to:
> acl allow all all
> What are the steps in creating / configuring a QPID user in a Windows 
> environment?
> Thanks in advance,
> Nathan.



--
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-3319) org.apache.qpid.server.subscription.SubscriptionList leaks memory

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-3319:
--
Component/s: Java Broker

> org.apache.qpid.server.subscription.SubscriptionList leaks memory
> -
>
> Key: QPID-3319
> URL: https://issues.apache.org/jira/browse/QPID-3319
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Danushka Menikkumbura
>Assignee: Keith Wall
>Priority: Critical
> Attachments: QPID-3319-26-07-2011.patch, QPID-3319-26-07-2011.patch, 
> QPID-3319.2.patch, QPID-3319.3.patch, QPID-3319.patch
>
>




--
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] [Closed] (QPID-4273) qpid-cpp Makefile for swig bindings overwrites DESTDIR

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-4273.
-

> qpid-cpp Makefile for swig bindings overwrites DESTDIR
> --
>
> Key: QPID-4273
> URL: https://issues.apache.org/jira/browse/QPID-4273
> Project: Qpid
>  Issue Type: Bug
>  Components: Build Tools
>Affects Versions: 0.16
> Environment: I'm packaging (unofficially) for gentoo.
>Reporter: Travis Glenn Hansen
> Attachments: swig-perl-bad-destdir.patch
>
>
> The build system's DESTDIR value is being ignore due to the use of 
> DESTDIR=$(prefix) in the Makefile.  There are 2 effects of this...
> 1. prefix becomes double accounted for so it's trying to install to /usr/usr 
> in my case
> 2. we're writing to the live filesystem instead of the sandbox which makes 
> the build fail



--
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] [Closed] (QPID-6942) [Documentation] Generate docbook artifacts into the same folders as used on site

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-6942.
-

> [Documentation] Generate docbook artifacts into the same folders as used on 
> site
> 
>
> Key: QPID-6942
> URL: https://issues.apache.org/jira/browse/QPID-6942
> Project: Qpid
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Alex Rudyy
>
> Currently Java Components docbooks are generated into folders different from 
> the used on site. As result, on updating the site for new release 
> cross-references between docbooks needs to be fixed by doing search/replace 
> as part of template generation process. That can be easily avoided by putting 
> the docbooks artifacts into the folders as used on site.
> For example, Java Broker html docbook pages need to be stored in folder 
> java-broker/book rather then AMQP-Messaging-Broker-Java-Book/html and JMS-0-8 
> client  html docbook pages need to be stored in folder jms-client-0-8/book. 
> The cross links needs to be corrected accordingly. Also, the links to cpp 
> broker docbook and programming in qpid docbook should be changed as well.



--
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] [Closed] (QPID-3005) Cmake build on Linux leaves #[bin_dir]src droppings

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-3005.
-

> Cmake build on Linux leaves #[bin_dir]src droppings
> ---
>
> Key: QPID-3005
> URL: https://issues.apache.org/jira/browse/QPID-3005
> Project: Qpid
>  Issue Type: Bug
>  Components: Build Tools
>Affects Versions: 0.6, 0.8
> Environment: Fedora12-14/RHEL 5
>Reporter: Andrew Stitcher
>
> Doing a simple "cmake; make" style build leaves a directory called 
> "#[bin_dir]src" in my home directory, I've also seen the directory created in 
> other places but I'm not entorely sure what the trigger for the different 
> locations is.
> I think this is somehow related to the install location specification judging 
> by the contents of the directories.



--
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] [Closed] (QPID-182) Remove code from AMQSession for "old GRM hack"

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-182.


> Remove code from AMQSession for "old GRM hack"
> --
>
> Key: QPID-182
> URL: https://issues.apache.org/jira/browse/QPID-182
> Project: Qpid
>  Issue Type: Improvement
>  Components: Dot Net Client, Java Client
>Reporter: Steven Shaw
>Assignee: Steven Shaw
>Priority: Minor
>
> The code in question is no longer required as a proper fix was subsequently 
> applied to the code.



--
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] [Closed] (QPID-7230) Broker terminates the connection to JMS Client

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-7230.
-

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log, ben-trace.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't 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] [Closed] (QPID-1933) QMF Java Console

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-1933.
-

> QMF Java Console
> 
>
> Key: QPID-1933
> URL: https://issues.apache.org/jira/browse/QPID-1933
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Client, Java Tools, Qpid Managment Framework
>Reporter: Bryan Kearney
>Assignee: Ted Ross
> Attachments: javaConsole.patch
>
>
> Add a java console which can access the QMF Bus.



--
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] [Closed] (QPID-764) .Net can cause negative reference count on Java broker.

[Justin Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed QPID-764.


> .Net can cause negative reference count on Java broker.
> ---
>
> Key: QPID-764
> URL: https://issues.apache.org/jira/browse/QPID-764
> Project: Qpid
>  Issue Type: Bug
>  Components: Dot Net Client, Java Broker
>Affects Versions: M2
>Reporter: Rupert Smith
>
> ... if channels not closed properly. Added Close() methods to 
> channels/publishers/consumers so that things can be closed down properly. 
> Lack of closing meant that multiple acks are being send.
> However, reference counting is internal to the broker, and should not go 
> negative even if clients misbehave, so creating this JIRA for resolution 
> against the JAva broker. Test case to follow...



--
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

Re: Closing connection whilst MessageListener in-flight delivery is in progress

[Robbie Gemmell]

On 9 December 2016 at 16:40, Oleksandr Rudyy  wrote:
> Hi,
>
> Recently I noticed that new jms client can fail to acknowledge the
> message (with auto-ack delivery mode) which was in a process of
> delivery with MessageListener when Connection#close() is called from
> main application thread.
>
> The exception like the one below is delivered into ExceptionListener:
> Connection ExceptionListener fired, exiting.
> javax.jms.IllegalStateException: The MessageConsumer is closed
> at 
> org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:328)
> at 
> org.apache.qpid.jms.JmsMessageConsumer.doAckConsumed(JmsMessageConsumer.java:372)
> at 
> org.apache.qpid.jms.JmsMessageConsumer.access$600(JmsMessageConsumer.java:52)
> at 
> org.apache.qpid.jms.JmsMessageConsumer$MessageDeliverTask.run(JmsMessageConsumer.java:679)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>
> Although such behavior could be considered JMS spec compliment, as the
> specs states in "4.3.5 Closing a Connection" of JMS spec 1.1:
> "If one or more of the connection’s session’s message listeners is processing 
> a
> message at the point when connection close is invoked, all the facilities of 
> the
> connection and its sessions must remain available to those listeners until 
> they
> return control to the JMS provider."
>
> Thus, it seems that closing of the connection is allowed without
> sending the acknowledgment, as acknowledgment is sent after the
> control is returned to JMS provider.
>
> However, from practical point of view such behavior might not be
> desirable, as it causes duplicate message deliveries for those
> messages not being acknowledged  on close. I would expect from the
> client to acknowledge the delivered messages with
> MessageConsume#onMessage before the connection close.
>
> Are there any plans to change the client to wait for in-flight message
> delivery acknowledgment  before closing the connection?
>
> Kind Regards,
> Alex
>

No existings plans, feel free to JIRA it :)

Robbie

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7432) Make python management tools work over AMQP 1.0

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-7432:
-
Component/s: Python Tools

> Make python management tools work over AMQP 1.0
> ---
>
> Key: QPID-7432
> URL: https://issues.apache.org/jira/browse/QPID-7432
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, Python Tools
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: qpid-cpp-1.36.0
>
>
> The qpid management tools and the qpidtoollib python library should work over 
> AMQP 1.0. Verify and fix any issues.



--
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-7432) Make python management tools work over AMQP 1.0

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-7432:
-
Fix Version/s: qpid-cpp-1.36.0

> Make python management tools work over AMQP 1.0
> ---
>
> Key: QPID-7432
> URL: https://issues.apache.org/jira/browse/QPID-7432
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: qpid-cpp-1.36.0
>
>
> The qpid management tools and the qpidtoollib python library should work over 
> AMQP 1.0. Verify and fix any issues.



--
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-7584) qpid-cpp 1.36.0 release tasks

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735832#comment-15735832
 ] 

ASF subversion and git services commented on QPID-7584:
---

Commit 97afe01e2b621d8e241be0bc74e035635d86f923 in qpid-cpp's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=97afe01 ]

QPID-7584: update versions etc for 1.37.0(-SNAPSHOT) on master


> qpid-cpp 1.36.0 release tasks
> -
>
> Key: QPID-7584
> URL: https://issues.apache.org/jira/browse/QPID-7584
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-cpp-1.36.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] (QPID-7584) qpid-cpp 1.36.0 release tasks

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735827#comment-15735827
 ] 

ASF subversion and git services commented on QPID-7584:
---

Commit d92ba2063c020235b5099335c89349099cea0e9e in qpid-cpp's branch 
refs/heads/1.36.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=d92ba20 ]

QPID-7584: update versions etc for 1.36.0


> qpid-cpp 1.36.0 release tasks
> -
>
> Key: QPID-7584
> URL: https://issues.apache.org/jira/browse/QPID-7584
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-cpp-1.36.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] [Updated] (QPID-6774) Can't compile unit_test with boost 1.59.0

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-6774:
-
Fix Version/s: (was: qpid-cpp-1.36.0)
   qpid-cpp-1.37.0

> Can't compile unit_test with boost 1.59.0
> -
>
> Key: QPID-6774
> URL: https://issues.apache.org/jira/browse/QPID-6774
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
> Fix For: qpid-cpp-1.37.0
>
>
> QPID-6771:
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE": 
> 找不到标识符
> BOOST_MESSAGE was removed from boost 1.59.0, we should add it.
>  
> from:
> namespace tests {
> QPID_AUTO_TEST_SUITE(exception_test)
> to:
> namespace tests {
> #ifndef BOOST_MESSAGE
> #define BOOST_MESSAGE( M )  BOOST_TEST_MESSAGE( M )
> #endif
> QPID_AUTO_TEST_SUITE(exception_test)



--
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-7236) Uninitialised values in AclRule

[Gordon Sim (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim updated QPID-7236:
-
Fix Version/s: (was: qpid-cpp-1.36.0)

> Uninitialised values in AclRule
> ---
>
> Key: QPID-7236
> URL: https://issues.apache.org/jira/browse/QPID-7236
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> Valgrind shows reads of uninitialised action/object.



--
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-7584) qpid-cpp 1.36.0 release tasks

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735736#comment-15735736
 ] 

ASF subversion and git services commented on QPID-7584:
---

Commit 1f8acbd9893bb503512451c3e92e776a612153c0 in qpid-cpp's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=1f8acbd ]

QPID-7584: add some details/helpers for doing qpid-cpp release


> qpid-cpp 1.36.0 release tasks
> -
>
> Key: QPID-7584
> URL: https://issues.apache.org/jira/browse/QPID-7584
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-cpp-1.36.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

Closing connection whilst MessageListener in-flight delivery is in progress

[Oleksandr Rudyy]

Hi,

Recently I noticed that new jms client can fail to acknowledge the
message (with auto-ack delivery mode) which was in a process of
delivery with MessageListener when Connection#close() is called from
main application thread.

The exception like the one below is delivered into ExceptionListener:
Connection ExceptionListener fired, exiting.
javax.jms.IllegalStateException: The MessageConsumer is closed
at 
org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:328)
at 
org.apache.qpid.jms.JmsMessageConsumer.doAckConsumed(JmsMessageConsumer.java:372)
at 
org.apache.qpid.jms.JmsMessageConsumer.access$600(JmsMessageConsumer.java:52)
at 
org.apache.qpid.jms.JmsMessageConsumer$MessageDeliverTask.run(JmsMessageConsumer.java:679)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Although such behavior could be considered JMS spec compliment, as the
specs states in "4.3.5 Closing a Connection" of JMS spec 1.1:
"If one or more of the connection’s session’s message listeners is processing a
message at the point when connection close is invoked, all the facilities of the
connection and its sessions must remain available to those listeners until they
return control to the JMS provider."

Thus, it seems that closing of the connection is allowed without
sending the acknowledgment, as acknowledgment is sent after the
control is returned to JMS provider.

However, from practical point of view such behavior might not be
desirable, as it causes duplicate message deliveries for those
messages not being acknowledged  on close. I would expect from the
client to acknowledge the delivered messages with
MessageConsume#onMessage before the connection close.

Are there any plans to change the client to wait for in-flight message
delivery acknowledgment  before closing the connection?

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7584) qpid-cpp 1.36.0 release tasks

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-7584:
-
Assignee: Robbie Gemmell  (was: Justin Ross)
Reporter: Robbie Gemmell  (was: Justin Ross)

> qpid-cpp 1.36.0 release tasks
> -
>
> Key: QPID-7584
> URL: https://issues.apache.org/jira/browse/QPID-7584
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-cpp-1.36.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] [Updated] (QPID-7584) qpid-cpp 1.36.0 release tasks

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-7584:
-
Fix Version/s: (was: qpid-cpp-1.35.0)
   qpid-cpp-1.36.0

> qpid-cpp 1.36.0 release tasks
> -
>
> Key: QPID-7584
> URL: https://issues.apache.org/jira/browse/QPID-7584
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.36.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] (QPID-7584) qpid-cpp 1.36.0 release tasks

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPID-7584:


 Summary: qpid-cpp 1.36.0 release tasks
 Key: QPID-7584
 URL: https://issues.apache.org/jira/browse/QPID-7584
 Project: Qpid
  Issue Type: Task
  Components: C++ Broker, C++ Client
Reporter: Justin Ross
Assignee: Justin Ross
 Fix For: qpid-cpp-1.35.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] [Resolved] (QPID-7578) [Java Broker] make AMQP 1.0 temporary queues globally addressable

[Lorenz Quack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lorenz Quack resolved QPID-7578.

Resolution: Fixed

> [Java Broker] make AMQP 1.0 temporary queues globally addressable 
> --
>
> Key: QPID-7578
> URL: https://issues.apache.org/jira/browse/QPID-7578
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.2
>
>
> In AMQP 1.0 temporary queues currently have a random UUID as name.
> In the other protocols we prefix that with the primary global domain of the 
> virtual host to make it globally addressable. We should do the same for AMQP 
> 1.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] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[Lorenz Quack (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735661#comment-15735661
 ] 

Lorenz Quack commented on QPID-7546:


Previously there was a race in the test where the client would close the async 
consumer after the onMessage had returned but before the message was 
auto-acked. The fix uses a transacted session to remove the race.

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
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-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735655#comment-15735655
 ] 

ASF subversion and git services commented on QPID-7546:
---

Commit 1773417 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1773417 ]

QPID-7546: Make PropertyValueTest pass with new JMS client.

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
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-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735406#comment-15735406
 ] 

ASF subversion and git services commented on QPID-7546:
---

Commit 1773400 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1773400 ]

QPID-7546: Fix disttest EndToEndTest to run for AMQP 1.0

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
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] (DISPATCH-592) Attempt to auto-login to the host:port that served the web page

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-592:
-

 Summary: 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] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735268#comment-15735268
 ] 

ASF subversion and git services commented on QPID-7546:
---

Commit 1773375 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1773375 ]

QPID-7546 : Move excluded test 
CommitRollbackTest#testSend2ThenCloseAfter1andTryAgain from 
Java10BrokenTestsExcludes into Java10Excludes and update exclusion reason

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
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-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735243#comment-15735243
 ] 

ASF subversion and git services commented on QPID-7546:
---

Commit 1773369 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1773369 ]

QPID-7546: fix producer flow control test and move test for client flow control 
behaviour into separate test class

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
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-7583) [Java Broker] On AMQP 1.0 ensure Flow is sent to client when producer flow control changes state

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735241#comment-15735241
 ] 

ASF subversion and git services commented on QPID-7583:
---

Commit 1773368 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1773368 ]

QPID-7583: [Java Broker] On AMQP 1.0 ensure Flow is sent to client when 
producer flow control changes state

> [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
>
> 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

[Lorenz Quack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lorenz Quack updated QPID-7583:
---
Summary: [Java Broker] On AMQP 1.0 ensure Flow is sent to client when 
producer flow control changes state  (was: [Java Broker] Ensure Flow is sent to 
client when producer flow control changes state)

> [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
>
> 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] [Created] (QPID-7583) [Java Broker] Ensure Flow is sent to client when producer flow control changes state

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7583:
--

 Summary: [Java Broker] 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


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] [Commented] (QPIDJMS-230) AmqpFixedProducer created for every message sent

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735102#comment-15735102
 ] 

Robbie Gemmell commented on QPIDJMS-230:


Its not a settings problem but a matter of support for an extension capability. 
You are using two different servers, one supports something and the other does 
not.

The Azure server is not advertising support for the 'anonymous relay' 
extension, so the client doesnt try to use it, and has falls back to opening 
(and closing, since you may have an unbounded number of destinations) 
individual links per-send when using an 'anonymous' JMS producer created 
without a specific destination. ActiveMQ does advertise support, so against 
that broker the client utilizes it to allow using a single 'anonymous sender' 
link for the 'anonymous' JMS producer, thus giving different behaviour.

To follow up on the last bit of my previous comment, the optional and 
untested/unused caching doesn't appear to be functional and so wouldn't 
currently be an option.

I've never used the connector/bridge functionality you are using so I don't 
know if its possible to configure things to utilise producers with a fixed 
destination, but I think that would currently be your only path to avoiding the 
behaviour against Azure.

> AmqpFixedProducer created for every message sent
> 
>
> Key: QPIDJMS-230
> URL: https://issues.apache.org/jira/browse/QPIDJMS-230
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Milan Nikl
>Priority: Minor
>  Labels: performance
> Attachments: amqps_frames.log, apache.qpid.log
>
>
> *Configuration:* Hi, I'm using ActiveMQ 5.14.1 to connect from a device 
> (running linux derivate OS) to Azure IoT Hub. With Qpid JMS client 0.11.1 and 
> protonj 0.15.0 providing AMQPS based JmsConnection implementation. I'm using 
> Destination bridges to connect my local queues to remote queues.
> *Problem description:* For every message I send to the server there is new 
> connection attempt made. I can see those reconnections in Azure IoT Hub 
> monitoring, in AMQPS frames logs, qpid log etc. And while I have the same 
> JmsConnection instance active for the whole time, in reality the device keeps 
> connecting and disconnecting for each message, which presents additional load 
> for both IoT Hub and device. Message throughput is really affected by this 
> behaviour.
> When I try running similar code from my desktop using Qpid JMS client 0.11.1 
> to send messages, it creates single AmqpFixedProducer at start and 
> disconnects when all messages are sent. I'm not aware of any special 
> settings, both application use JmsConnectionFactory.setForceSyncSend(true).
> So ActiveMQ or some of its components could be blamed for this. But I would 
> like to know if someone has any experience with similar problem and maybe 
> some idea how to solve it.
> Thanks!
> Attachments: In logs you can see the device connecting, then some already 
> enqueued messages are sent. Once the initial load is processed, one message 
> per minute should be sent.
> Originaly filed in 
> http://qpid.2158936.n2.nabble.com/AmqpFixedProducer-created-for-every-message-sent-td7655816.html



--
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-231) closing a consumer used since prior commit/rollback holds its prefetched messages until the next commit/rollback

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPIDJMS-231:
---
Summary: closing a consumer used since prior commit/rollback holds its 
prefetched messages until the next commit/rollback  (was: Prefetched messages 
are not released on consumer  close)

Updated title to reflect that the issue is more nuanced. It isn't simply that 
it doesnt release prefetched messages on consumer close (which is often not 
going to be required, as closing the link implicitly ends any hold the link has 
on them), but that in the case you actually encountered the sessions current 
transaction was still in progress with messages previously consumed using that 
JMS consumer before it was closed. The client is currently handling that 
scenario by not closing the link until the commit/rollback, which with 
prefetching enabled creates the issue you saw should you want to consume them 
using other consumers in the same transaction before calling commit/rollback.

> closing a consumer used since prior commit/rollback holds its prefetched 
> messages until the next commit/rollback
> 
>
> Key: QPIDJMS-231
> URL: https://issues.apache.org/jira/browse/QPIDJMS-231
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.11.0
>Reporter: Alex Rudyy
>
> The messages prefetched by the consumer and not yet delivered to the 
> application are not released on consumer close. As result, the new consumer 
> cannot consume the messages prefetched by closed consumer. 
> This issue was discovered for a transacted consumer. I did not investigate 
> whether other acknowledgment modes are affected by it.



--
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

Re: Issue with prefetched messages not being released immediately on consumer close

[Oleksandr Rudyy]

Robbie,

I raised JIRA https://issues.apache.org/jira/browse/QPIDJMS-231 for the issue

Alex

On 7 December 2016 at 17:50, Robbie Gemmell  wrote:
> On 7 December 2016 at 16:27, Oleksandr Rudyy  wrote:
>> Hi ,
>>
>> We were looking into failing  system tests for AMQP 1.0 and discovered
>> that transacted Consumer#close() does not release any prefetched
>> messages immediately. It seems that transactions needs to be finished
>> (committed/rolled back). As result, if another consumer is created
>> before the transaction end, it will not see the acquired messages by
>> closed consumer. Because of this issue the test
>> org.apache.qpid.test.unit.transacted.CommitRollbackTest#testSend2ThenCloseAfter1andTryAgain
>> is failing, as it creates a second consumer and tries to consume the
>> message with this consumer before the transaction for the first closed
>> consumer is committed.
>>
>> It is unclear whether it is a correct behavior or not. However, the
>> legacy JMS client for AMQP 0.x is passing the test. We have to exclude
>> the test from running on AMQP 1.0 profile.
>>
>> Shall I raise a JIRA about this issue?
>>
>> Kind Regards,
>> Alex
>>
>
> Yes, please raise a JIRA. It isnt explicitly releasing messages on
> closing the links...and its handling that particular situation by not
> actually closing the link yet, thus it will currently act as the test
> has found.
>
> Robbie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPIDJMS-231) Prefetched messages are not released on consumer close

[Alex Rudyy (JIRA)]

Alex Rudyy created QPIDJMS-231:
--

 Summary: Prefetched messages are not released on consumer  close
 Key: QPIDJMS-231
 URL: https://issues.apache.org/jira/browse/QPIDJMS-231
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.11.0
Reporter: Alex Rudyy


The messages prefetched by the consumer and not yet delivered to the 
application are not released on consumer close. As result, the new consumer 
cannot consume the messages prefetched by closed consumer. 

This issue was discovered for a transacted consumer. I did not investigate 
whether other acknowledgment modes are affected by it.




--
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] [Closed] (QPIDJMS-230) AmqpFixedProducer created for every message sent

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell closed QPIDJMS-230.
--
Resolution: Not A Bug

> AmqpFixedProducer created for every message sent
> 
>
> Key: QPIDJMS-230
> URL: https://issues.apache.org/jira/browse/QPIDJMS-230
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Milan Nikl
>Priority: Minor
>  Labels: performance
> Attachments: amqps_frames.log, apache.qpid.log
>
>
> *Configuration:* Hi, I'm using ActiveMQ 5.14.1 to connect from a device 
> (running linux derivate OS) to Azure IoT Hub. With Qpid JMS client 0.11.1 and 
> protonj 0.15.0 providing AMQPS based JmsConnection implementation. I'm using 
> Destination bridges to connect my local queues to remote queues.
> *Problem description:* For every message I send to the server there is new 
> connection attempt made. I can see those reconnections in Azure IoT Hub 
> monitoring, in AMQPS frames logs, qpid log etc. And while I have the same 
> JmsConnection instance active for the whole time, in reality the device keeps 
> connecting and disconnecting for each message, which presents additional load 
> for both IoT Hub and device. Message throughput is really affected by this 
> behaviour.
> When I try running similar code from my desktop using Qpid JMS client 0.11.1 
> to send messages, it creates single AmqpFixedProducer at start and 
> disconnects when all messages are sent. I'm not aware of any special 
> settings, both application use JmsConnectionFactory.setForceSyncSend(true).
> So ActiveMQ or some of its components could be blamed for this. But I would 
> like to know if someone has any experience with similar problem and maybe 
> some idea how to solve it.
> Thanks!
> Attachments: In logs you can see the device connecting, then some already 
> enqueued messages are sent. Once the initial load is processed, one message 
> per minute should be sent.
> Originaly filed in 
> http://qpid.2158936.n2.nabble.com/AmqpFixedProducer-created-for-every-message-sent-td7655816.html



--
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-230) AmqpFixedProducer created for every message sent

[Milan Nikl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Milan Nikl updated QPIDJMS-230:
---
Attachment: apache.qpid.log
amqps_frames.log

- Logs are showing connection to the IoT hub, sending about 10 messages after 
connection an then 1 message per minute.
- Disconnecting and reconnecting on AMQPS level is easy to see
- AmqpFixedProdusers are created with matching frequency

> AmqpFixedProducer created for every message sent
> 
>
> Key: QPIDJMS-230
> URL: https://issues.apache.org/jira/browse/QPIDJMS-230
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Milan Nikl
>Priority: Minor
>  Labels: performance
> Attachments: amqps_frames.log, apache.qpid.log
>
>
> *Configuration:* Hi, I'm using ActiveMQ 5.14.1 to connect from a device 
> (running linux derivate OS) to Azure IoT Hub. With Qpid JMS client 0.11.1 and 
> protonj 0.15.0 providing AMQPS based JmsConnection implementation. I'm using 
> Destination bridges to connect my local queues to remote queues.
> *Problem description:* For every message I send to the server there is new 
> connection attempt made. I can see those reconnections in Azure IoT Hub 
> monitoring, in AMQPS frames logs, qpid log etc. And while I have the same 
> JmsConnection instance active for the whole time, in reality the device keeps 
> connecting and disconnecting for each message, which presents additional load 
> for both IoT Hub and device. Message throughput is really affected by this 
> behaviour.
> When I try running similar code from my desktop using Qpid JMS client 0.11.1 
> to send messages, it creates single AmqpFixedProducer at start and 
> disconnects when all messages are sent. I'm not aware of any special 
> settings, both application use JmsConnectionFactory.setForceSyncSend(true).
> So ActiveMQ or some of its components could be blamed for this. But I would 
> like to know if someone has any experience with similar problem and maybe 
> some idea how to solve it.
> Thanks!
> Attachments: In logs you can see the device connecting, then some already 
> enqueued messages are sent. Once the initial load is processed, one message 
> per minute should be sent.
> Originaly filed in 
> http://qpid.2158936.n2.nabble.com/AmqpFixedProducer-created-for-every-message-sent-td7655816.html



--
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-230) AmqpFixedProducer created for every message sent

[Milan Nikl (JIRA)]

Milan Nikl created QPIDJMS-230:
--

 Summary: AmqpFixedProducer created for every message sent
 Key: QPIDJMS-230
 URL: https://issues.apache.org/jira/browse/QPIDJMS-230
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.11.1
Reporter: Milan Nikl
Priority: Minor


*Configuration:* Hi, I'm using ActiveMQ 5.14.1 to connect from a device 
(running linux derivate OS) to Azure IoT Hub. With Qpid JMS client 0.11.1 and 
protonj 0.15.0 providing AMQPS based JmsConnection implementation. I'm using 
Destination bridges to connect my local queues to remote queues.

*Problem description:* For every message I send to the server there is new 
connection attempt made. I can see those reconnections in Azure IoT Hub 
monitoring, in AMQPS frames logs, qpid log etc. And while I have the same 
JmsConnection instance active for the whole time, in reality the device keeps 
connecting and disconnecting for each message, which presents additional load 
for both IoT Hub and device. Message throughput is really affected by this 
behaviour.

When I try running similar code from my desktop using Qpid JMS client 0.11.1 to 
send messages, it creates single AmqpFixedProducer at start and disconnects 
when all messages are sent. I'm not aware of any special settings, both 
application use JmsConnectionFactory.setForceSyncSend(true).

So ActiveMQ or some of its components could be blamed for this. But I would 
like to know if someone has any experience with similar problem and maybe some 
idea how to solve it.

Thanks!

Attachments: In logs you can see the device connecting, then some already 
enqueued messages are sent. Once the initial load is processed, one message per 
minute should be sent.

Originaly filed in 
http://qpid.2158936.n2.nabble.com/AmqpFixedProducer-created-for-every-message-sent-td7655816.html



--
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