[jira] [Commented] (DISPATCH-871) Performance issues with large messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-871:
-

Github user asfgit closed the pull request at:

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


> Performance issues with large messages
> --
>
> Key: DISPATCH-871
> URL: https://issues.apache.org/jira/browse/DISPATCH-871
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
>
> A performance regression has been seen by several testers of the release 
> candidate.  This Jira will track the issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-867) Messages stuck going through link route

[ASF subversion and git services (JIRA)]

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

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

Commit a512c083342e497c3c461163fb0ffd946fe586d5 in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a512c08 ]

DISPATCH-867 - Added missing linkage from drained output buffer to restarting a 
stalled link.
This closes #215


> Messages stuck going through link route
> ---
>
> Key: DISPATCH-867
> URL: https://issues.apache.org/jira/browse/DISPATCH-867
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
> Environment: Fedora 25
> master branch at commit fff38466
>Reporter: Chuck Rolke
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Sending 10 each 100kbyte messages, presettled, to a link route:
> * 10 messages go in
> * 5, 6, or 7 messages come out
> A single transfer of the 'stuck' message goes out over the wire and then the 
> router stops sending.
> The remaining messages are visible as undelivered in qdstat



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #215: DISPATCH-871 - Connect the release of outbo...

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[jira] [Resolved] (DISPATCH-865) Segmentation fault while running 2-node Artemis tests

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-865.
---
Resolution: Fixed

> Segmentation fault while running 2-node Artemis tests
> -
>
> Key: DISPATCH-865
> URL: https://issues.apache.org/jira/browse/DISPATCH-865
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Kim van der Riet
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
> Attachments: qdrouterd.node1.conf, qdrouterd.node2.conf
>
>
> While running qpid-interop-test against a 2-node + broker configuration, node 
> 2 fails with a segmentation fault.  The configuration is as follows:
> {noformat}
> 9001   5672   56729002
> Sender ---> Node1 --> Artemis --> Node 2 --> Receiver
> {noformat}
> The configuration files for nodes 1 and 2 are attached.
> The client is {{amqp_types_test}} from qpid-interop-test, and is run as 
> follows:
> {noformat}
> amqp_types_test.py --sender localhost:9001 --receiver localhost:9002
> Test Broker: qpid-dispatch-router v.1.0.0 on 
> test_binary_ProtonCpp->ProtonCpp (__main__.BinaryTestCase) ... ok
> test_binary_ProtonCpp->ProtonPython (__main__.BinaryTestCase) ...
> {noformat}
> which is where the test hangs, and where node 2 fails. Using gdb, I see the 
> following stacktrace:
> {noformat}
> Thread 5 "qdrouterd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffe882e700 (LWP 16963)]
> 0x77bb6c8b in qdr_node_disconnect_deliveries (core=0x8fcec0, 
> link=0x0, qdlv=qdlv@entry=0x7fffdc030610, pdlv=pdlv@entry=0x7fffd40008d0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:76
> 76DEQ_REMOVE(*list, ref);
> (gdb) bt
> #0  0x77bb6c8b in qdr_node_disconnect_deliveries (core=0x8fcec0, 
> link=0x0, qdlv=qdlv@entry=0x7fffdc030610, pdlv=pdlv@entry=0x7fffd40008d0)
> at /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:76
> #1  0x77bb6fbf in CORE_delivery_update (context=0x89d570, 
> dlv=0x7fffdc030610, disp=36, settled=) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:1435
> #2  0x77baa255 in qdr_connection_process (conn=0x95f5d0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_core/connections.c:316
> #3  0x77b95668 in writable_handler (container=0x89d3d0, 
> container=0x89d3d0, conn=0x7fffe000a360, qd_conn=0x7fffeb50) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/container.c:329
> #4  qd_container_handle_event (container=0x89d3d0, 
> event=event@entry=0x7fffe002f3e0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/container.c:552
> #5  0x77bbb3b5 in handle (qd_server=qd_server@entry=0x883dc0, 
> e=0x7fffe002f3e0) at /home/kpvdr/RedHat/qpid-dispatch/src/server.c:912
> #6  0x77bbc0d8 in thread_run (arg=0x883dc0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/server.c:930
> #7  0x775185ca in start_thread (arg=0x7fffe882e700) at 
> pthread_create.c:333
> #8  0x767eb0cd in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {noformat}
> and occurs 100% of the time.
> Qpid Dispatch version: master as of Nov 2, 2017



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-865) Segmentation fault while running 2-node Artemis tests

[ASF subversion and git services (JIRA)]

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

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

Commit ede8b029a322c0f208359ecb47365daab648552d in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ede8b02 ]

DISPATCH-865 - Don't account for delivery linkage when there is no link.


> Segmentation fault while running 2-node Artemis tests
> -
>
> Key: DISPATCH-865
> URL: https://issues.apache.org/jira/browse/DISPATCH-865
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Kim van der Riet
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
> Attachments: qdrouterd.node1.conf, qdrouterd.node2.conf
>
>
> While running qpid-interop-test against a 2-node + broker configuration, node 
> 2 fails with a segmentation fault.  The configuration is as follows:
> {noformat}
> 9001   5672   56729002
> Sender ---> Node1 --> Artemis --> Node 2 --> Receiver
> {noformat}
> The configuration files for nodes 1 and 2 are attached.
> The client is {{amqp_types_test}} from qpid-interop-test, and is run as 
> follows:
> {noformat}
> amqp_types_test.py --sender localhost:9001 --receiver localhost:9002
> Test Broker: qpid-dispatch-router v.1.0.0 on 
> test_binary_ProtonCpp->ProtonCpp (__main__.BinaryTestCase) ... ok
> test_binary_ProtonCpp->ProtonPython (__main__.BinaryTestCase) ...
> {noformat}
> which is where the test hangs, and where node 2 fails. Using gdb, I see the 
> following stacktrace:
> {noformat}
> Thread 5 "qdrouterd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffe882e700 (LWP 16963)]
> 0x77bb6c8b in qdr_node_disconnect_deliveries (core=0x8fcec0, 
> link=0x0, qdlv=qdlv@entry=0x7fffdc030610, pdlv=pdlv@entry=0x7fffd40008d0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:76
> 76DEQ_REMOVE(*list, ref);
> (gdb) bt
> #0  0x77bb6c8b in qdr_node_disconnect_deliveries (core=0x8fcec0, 
> link=0x0, qdlv=qdlv@entry=0x7fffdc030610, pdlv=pdlv@entry=0x7fffd40008d0)
> at /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:76
> #1  0x77bb6fbf in CORE_delivery_update (context=0x89d570, 
> dlv=0x7fffdc030610, disp=36, settled=) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:1435
> #2  0x77baa255 in qdr_connection_process (conn=0x95f5d0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_core/connections.c:316
> #3  0x77b95668 in writable_handler (container=0x89d3d0, 
> container=0x89d3d0, conn=0x7fffe000a360, qd_conn=0x7fffeb50) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/container.c:329
> #4  qd_container_handle_event (container=0x89d3d0, 
> event=event@entry=0x7fffe002f3e0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/container.c:552
> #5  0x77bbb3b5 in handle (qd_server=qd_server@entry=0x883dc0, 
> e=0x7fffe002f3e0) at /home/kpvdr/RedHat/qpid-dispatch/src/server.c:912
> #6  0x77bbc0d8 in thread_run (arg=0x883dc0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/server.c:930
> #7  0x775185ca in start_thread (arg=0x7fffe882e700) at 
> pthread_create.c:333
> #8  0x767eb0cd in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {noformat}
> and occurs 100% of the time.
> Qpid Dispatch version: master as of Nov 2, 2017



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (DISPATCH-865) Segmentation fault while running 2-node Artemis tests

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-865:
--
Priority: Blocker  (was: Major)

> Segmentation fault while running 2-node Artemis tests
> -
>
> Key: DISPATCH-865
> URL: https://issues.apache.org/jira/browse/DISPATCH-865
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Kim van der Riet
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
> Attachments: qdrouterd.node1.conf, qdrouterd.node2.conf
>
>
> While running qpid-interop-test against a 2-node + broker configuration, node 
> 2 fails with a segmentation fault.  The configuration is as follows:
> {noformat}
> 9001   5672   56729002
> Sender ---> Node1 --> Artemis --> Node 2 --> Receiver
> {noformat}
> The configuration files for nodes 1 and 2 are attached.
> The client is {{amqp_types_test}} from qpid-interop-test, and is run as 
> follows:
> {noformat}
> amqp_types_test.py --sender localhost:9001 --receiver localhost:9002
> Test Broker: qpid-dispatch-router v.1.0.0 on 
> test_binary_ProtonCpp->ProtonCpp (__main__.BinaryTestCase) ... ok
> test_binary_ProtonCpp->ProtonPython (__main__.BinaryTestCase) ...
> {noformat}
> which is where the test hangs, and where node 2 fails. Using gdb, I see the 
> following stacktrace:
> {noformat}
> Thread 5 "qdrouterd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffe882e700 (LWP 16963)]
> 0x77bb6c8b in qdr_node_disconnect_deliveries (core=0x8fcec0, 
> link=0x0, qdlv=qdlv@entry=0x7fffdc030610, pdlv=pdlv@entry=0x7fffd40008d0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:76
> 76DEQ_REMOVE(*list, ref);
> (gdb) bt
> #0  0x77bb6c8b in qdr_node_disconnect_deliveries (core=0x8fcec0, 
> link=0x0, qdlv=qdlv@entry=0x7fffdc030610, pdlv=pdlv@entry=0x7fffd40008d0)
> at /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:76
> #1  0x77bb6fbf in CORE_delivery_update (context=0x89d570, 
> dlv=0x7fffdc030610, disp=36, settled=) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_node.c:1435
> #2  0x77baa255 in qdr_connection_process (conn=0x95f5d0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/router_core/connections.c:316
> #3  0x77b95668 in writable_handler (container=0x89d3d0, 
> container=0x89d3d0, conn=0x7fffe000a360, qd_conn=0x7fffeb50) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/container.c:329
> #4  qd_container_handle_event (container=0x89d3d0, 
> event=event@entry=0x7fffe002f3e0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/container.c:552
> #5  0x77bbb3b5 in handle (qd_server=qd_server@entry=0x883dc0, 
> e=0x7fffe002f3e0) at /home/kpvdr/RedHat/qpid-dispatch/src/server.c:912
> #6  0x77bbc0d8 in thread_run (arg=0x883dc0) at 
> /home/kpvdr/RedHat/qpid-dispatch/src/server.c:930
> #7  0x775185ca in start_thread (arg=0x7fffe882e700) at 
> pthread_create.c:333
> #8  0x767eb0cd in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {noformat}
> and occurs 100% of the time.
> Qpid Dispatch version: master as of Nov 2, 2017



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-872) Add a counter for dropped-presettleds on links

[Ted Ross (JIRA)]

Ted Ross created DISPATCH-872:
-

 Summary: Add a counter for dropped-presettleds on links
 Key: DISPATCH-872
 URL: https://issues.apache.org/jira/browse/DISPATCH-872
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Router Node
Reporter: Ted Ross
 Fix For: 1.1.0


When the router drops pre-settled deliveries during congestion, those drops are 
not counted or reported.  A new counter should be added for links to account 
for dropped presettled deliveries.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (DISPATCH-867) Messages stuck going through link route

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-867:
-

Assignee: Ted Ross

> Messages stuck going through link route
> ---
>
> Key: DISPATCH-867
> URL: https://issues.apache.org/jira/browse/DISPATCH-867
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
> Environment: Fedora 25
> master branch at commit fff38466
>Reporter: Chuck Rolke
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Sending 10 each 100kbyte messages, presettled, to a link route:
> * 10 messages go in
> * 5, 6, or 7 messages come out
> A single transfer of the 'stuck' message goes out over the wire and then the 
> router stops sending.
> The remaining messages are visible as undelivered in qdstat



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (DISPATCH-867) Messages stuck going through link route

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-867:
--
Priority: Blocker  (was: Trivial)

> Messages stuck going through link route
> ---
>
> Key: DISPATCH-867
> URL: https://issues.apache.org/jira/browse/DISPATCH-867
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
> Environment: Fedora 25
> master branch at commit fff38466
>Reporter: Chuck Rolke
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Sending 10 each 100kbyte messages, presettled, to a link route:
> * 10 messages go in
> * 5, 6, or 7 messages come out
> A single transfer of the 'stuck' message goes out over the wire and then the 
> router stops sending.
> The remaining messages are visible as undelivered in qdstat



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1660) The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent version of json

[Gregor Berginc (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244524#comment-16244524
 ] 

Gregor Berginc commented on PROTON-1660:


With the release of 0.18.1, can you update the rubygem as well?

> The gemspec dependency on "json ~> 0" breaks anyone dependning on a recent 
> version of json
> --
>
> Key: PROTON-1660
> URL: https://issues.apache.org/jira/browse/PROTON-1660
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Reporter: Greg Blomquist
>Assignee: Alan Conway
> Fix For: proton-c-0.18.1
>
>
> https://github.com/apache/qpid-proton/blob/0790bb99fabc4a6d7c1c12fb09c0ff76a3594f5a/proton-c/bindings/ruby/qpid_proton.gemspec.in#L31
>  
> This line was recently changed in qpid-proton master. It causes any project 
> that depends on a recent version of json to break when pulling together 
> dependencies. The pessimistic style of version constraint means that 
> qpid-proton requires a json version of >= 0.0, but < 1. 
> For instance, our project has a dependency on json 2.x. And, we see this 
> error when bundling with qpid-proton: 
> {code:none} 
> Bundler could not find compatible versions for gem "json": 
>   In Gemfile: manageiq-providers-azure was resolved to 0.1.0, 
>   which depends on azure-armrest (~> 0.9.1) was resolved to 0.9.1, which 
> depends on json (~> 2.0.1) 
>   qpid_proton (~> 0.18) was resolved to 0.18.0, which depends on json (~> 0) 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (DISPATCH-867) Messages stuck going through link route

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-867:
--
Fix Version/s: 1.0.0

> Messages stuck going through link route
> ---
>
> Key: DISPATCH-867
> URL: https://issues.apache.org/jira/browse/DISPATCH-867
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
> Environment: Fedora 25
> master branch at commit fff38466
>Reporter: Chuck Rolke
>Priority: Trivial
> Fix For: 1.0.0
>
>
> Sending 10 each 100kbyte messages, presettled, to a link route:
> * 10 messages go in
> * 5, 6, or 7 messages come out
> A single transfer of the 'stuck' message goes out over the wire and then the 
> router stops sending.
> The remaining messages are visible as undelivered in qdstat



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (DISPATCH-871) Performance issues with large messages

[Ted Ross (JIRA)]

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

Ted Ross closed DISPATCH-871.
-
Resolution: Fixed

> Performance issues with large messages
> --
>
> Key: DISPATCH-871
> URL: https://issues.apache.org/jira/browse/DISPATCH-871
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
>
> A performance regression has been seen by several testers of the release 
> candidate.  This Jira will track the issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs

[Rob Godfrey (JIRA)]

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

Rob Godfrey reassigned QPID-8025:
-

Assignee: (was: Rob Godfrey)

> [Java Broker] Improve detach error message on unsubscribing from JMS shared 
> subs
> 
>
> Key: QPID-8025
> URL: https://issues.apache.org/jira/browse/QPID-8025
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Rob Godfrey
>
> On attempting to unsubscribe from a shared subscription, JMS requires an 
> error to occur if there exist active subscribers.  The error message returned 
> by the broker in this case currently refers to the queue the broker generates 
> for the durable subscription, the name of which is in effect an 
> implementation artefact.
> Since the particular implementation of shared subscriptions is essentially 
> JMS specific, it makes sense for the returned error message to be in terms of 
> the shared sub name, not the queue



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs

[ASF subversion and git services (JIRA)]

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

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

Commit e3aa40d97b8b79b9a7540d5055930c7a525c48d1 in qpid-broker-j's branch 
refs/heads/master from [~godfrer]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=e3aa40d ]

QPID-8025 : [Java Broker] Improve detach error message on unsubscribing from 
JMS shared subs


> [Java Broker] Improve detach error message on unsubscribing from JMS shared 
> subs
> 
>
> Key: QPID-8025
> URL: https://issues.apache.org/jira/browse/QPID-8025
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> On attempting to unsubscribe from a shared subscription, JMS requires an 
> error to occur if there exist active subscribers.  The error message returned 
> by the broker in this case currently refers to the queue the broker generates 
> for the durable subscription, the name of which is in effect an 
> implementation artefact.
> Since the particular implementation of shared subscriptions is essentially 
> JMS specific, it makes sense for the returned error message to be in terms of 
> the shared sub name, not the queue



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-8025:
--
Status: Reviewable  (was: In Progress)

> [Java Broker] Improve detach error message on unsubscribing from JMS shared 
> subs
> 
>
> Key: QPID-8025
> URL: https://issues.apache.org/jira/browse/QPID-8025
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> On attempting to unsubscribe from a shared subscription, JMS requires an 
> error to occur if there exist active subscribers.  The error message returned 
> by the broker in this case currently refers to the queue the broker generates 
> for the durable subscription, the name of which is in effect an 
> implementation artefact.
> Since the particular implementation of shared subscriptions is essentially 
> JMS specific, it makes sense for the returned error message to be in terms of 
> the shared sub name, not the queue



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs

[Rob Godfrey (JIRA)]

Rob Godfrey created QPID-8025:
-

 Summary: [Java Broker] Improve detach error message on 
unsubscribing from JMS shared subs
 Key: QPID-8025
 URL: https://issues.apache.org/jira/browse/QPID-8025
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Reporter: Rob Godfrey
Assignee: Rob Godfrey


On attempting to unsubscribe from a shared subscription, JMS requires an error 
to occur if there exist active subscribers.  The error message returned by the 
broker in this case currently refers to the queue the broker generates for the 
durable subscription, the name of which is in effect an implementation artefact.

Since the particular implementation of shared subscriptions is essentially JMS 
specific, it makes sense for the returned error message to be in terms of the 
shared sub name, not the queue



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-871) Performance issues with large messages

[Ted Ross (JIRA)]

Ted Ross created DISPATCH-871:
-

 Summary: Performance issues with large messages
 Key: DISPATCH-871
 URL: https://issues.apache.org/jira/browse/DISPATCH-871
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 1.0.0
Reporter: Ted Ross
Assignee: Ted Ross
Priority: Blocker
 Fix For: 1.0.0


A performance regression has been seen by several testers of the release 
candidate.  This Jira will track the issue.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-871) Performance issues with large messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-871:
-

GitHub user ted-ross opened a pull request:

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

DISPATCH-871 - Connect the release of outbound Q3 back-pressure from …

…proton back to the core.

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

$ git pull https://github.com/ted-ross/qpid-dispatch tross-DISPATCH-871

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

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


commit c708997949fe23dc966a9b0498268fb2e69a9a3a
Author: Ted Ross 
Date:   2017-11-08T17:24:59Z

DISPATCH-871 - Connect the release of outbound Q3 back-pressure from proton 
back to the core.




> Performance issues with large messages
> --
>
> Key: DISPATCH-871
> URL: https://issues.apache.org/jira/browse/DISPATCH-871
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.0.0
>
>
> A performance regression has been seen by several testers of the release 
> candidate.  This Jira will track the issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #215: DISPATCH-871 - Connect the release of outbo...

[ted-ross]

GitHub user ted-ross opened a pull request:

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

DISPATCH-871 - Connect the release of outbound Q3 back-pressure from …

…proton back to the core.

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

$ git pull https://github.com/ted-ross/qpid-dispatch tross-DISPATCH-871

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

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


commit c708997949fe23dc966a9b0498268fb2e69a9a3a
Author: Ted Ross 
Date:   2017-11-08T17:24:59Z

DISPATCH-871 - Connect the release of outbound Q3 back-pressure from proton 
back to the core.




---

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

[jira] [Comment Edited] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8017 at 11/8/17 4:44 PM:
---

The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm own 
each config change would look like this:

{code}
foreach registered JUL loggers available from 
java.util.logging.LogManager#getLoggerNames
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

Edit (16:45:00) 2017/11/08):

This idea above doesn't work for JUL loggers that don't yet exist (at the point 
in time configuration is made).   I suppose it could instead create a JUL 
logger for the class or package specified by the inclusion rule with the 
desired logging level. It would need to retain a reference to the JUL logger to 
stop is falling out of scope and being garbage collected to guard the case 
where the code that will use the logger has not yet been loaded.


was (Author: k-wall):
The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm own 
each config change would look like this:

{code}
foreach registered JUL loggers available from 
java.util.logging.LogManager#getLoggerNames
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

Edit:

This idea above doesn't work for JUL loggers that don't yet exist (at the point 
in time configuration is made).   I suppose it could instead create a JUL 
logger for the class or package specified by the inclusion rule with the 
desired logging level. It would need to retain a reference to the JUL logger to 
stop is falling out of scope and being garbage collected to guard the case 
where the code that will use the logger has not yet been loaded.

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> 

[jira] [Comment Edited] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8017 at 11/8/17 4:43 PM:
---

The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm own 
each config change would look like this:

{code}
foreach registered JUL loggers available from 
java.util.logging.LogManager#getLoggerNames
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

Edit:

This idea above doesn't work for JUL loggers that don't yet exist (at the point 
in time configuration is made).   I suppose it could instead create a JUL 
logger for the class or package specified by the inclusion rule with the 
desired logging level. It would need to retain a reference to the JUL logger to 
stop is falling out of scope and being garbage collected to guard the case 
where the code that will use the logger has not yet been loaded.


was (Author: k-wall):
The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm own 
each config change would look like this:

{code}
foreach registered JUL loggers available from 
java.util.logging.LogManager#getLoggerNames
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes 

[jira] [Updated] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-8018:
---
Status: Reviewable  (was: In Progress)

> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the 
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did 
> not respond in time. It might be that the client JVM was garbage collecting 
> and did not execute anything which resulted in a timeout, it might be a 
> network issue, and finally it also might be the server not responding in a 
> timely fashion.
> The error message should be clarified to more clearly express the actual 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7898) [Java 0-8...0-9-1 Client] Calling getJMSReplyTo on a received message can lead to NullPointerException

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7898:


Fun fact: if this problem is solved the next one pops right out: All calls to 
the {{NonBURLReplyToDestination}} constructor fail in {{AMQDestination:381}} 
because we pass in {{null}} as the {{exchangeClass}} in 
{{AMQMessageDelegate_0_8.NonBURLReplyToDestination#NonBURLReplyToDestination}}.

> [Java 0-8...0-9-1 Client] Calling getJMSReplyTo on a received message can 
> lead to NullPointerException
> --
>
> Key: QPID-7898
> URL: https://issues.apache.org/jira/browse/QPID-7898
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> A call to {{Message#getJMSReplyTo()}} can lead to a {{NullPointerException}}.
> {noformat}java.lang.NullPointerException
>   at 
> org.apache.qpid.client.message.AMQMessageDelegate_0_8.getJMSReplyTo(AMQMessageDelegate_0_8.java:301)
>   at 
> org.apache.qpid.client.message.AbstractJMSMessage.getJMSReplyTo(AbstractJMSMessage.java:104){noformat}
> The circumstances are
>  * a Message received over AMQP 0-8...0-9-1
>  * the replyTo set to a non-BURL address not containing a slash ("/") 
> The code throwing the NPE:
> {code:title=AMQMessageDelegate_0_8#getJMSReplyTo (slightly edited for 
> clarity)}public Destination getJMSReplyTo() throws JMSException
> {
> String replyToEncoding = 
> getContentHeaderProperties().getReplyToAsString();
> Destination dest;
> try {
> BindingURL binding = new AMQBindingURL(replyToEncoding);
> // something else
> } catch (URISyntaxException e) {
> if (replyToEncoding.startsWith("/")) {
> // something
> } else if (replyToEncoding.contains("/")) {
> // something
> } else if (getAMQSession().isQueueBound(replyToEncoding, null, null)) 
> {
> // THE ABOVE CALL TO getAMQSession THROWS A NPE!!!
> } else {
> // something
> }
> }
> return dest;
> }{code}
> The root cause seems to be that we are relying on the Message having 
> knowledge of the session but we aren't setting the Session on the Message on 
> all code paths.
> I encountered this testing message conversion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (QPID-8023) [Broker-J] Remove com.google.code.findbugs:jsr305 dependency

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8023.
--
Resolution: Fixed

> [Broker-J] Remove com.google.code.findbugs:jsr305 dependency
> 
>
> Key: QPID-8023
> URL: https://issues.apache.org/jira/browse/QPID-8023
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The update of Google Guava (QPID-7864) added a dependency on 
> com.google.code.findbugs:jsr305.  This is not required and should be excluded 
> from the Broker's distribution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-8018:
--

Assignee: (was: Lorenz Quack)

> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the 
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did 
> not respond in time. It might be that the client JVM was garbage collecting 
> and did not execute anything which resulted in a timeout, it might be a 
> network issue, and finally it also might be the server not responding in a 
> timely fashion.
> The error message should be clarified to more clearly express the actual 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8019.
--
Resolution: Fixed

> [Broker-J][WMC] Change link to broker documentation in web management console
> -
>
> Key: QPID-8019
> URL: https://issues.apache.org/jira/browse/QPID-8019
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> The link to broker documentation in WMC points to 
> [http://qpid.apache.org/components/java-broker/] at the moment. After 
> renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename 
> the location of Qpid Broker-J pages on qpid site. The suggested location of 
> broker-j pages is [http://qpid.apache.org/components/broker-j/] 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-8018:
--

Assignee: Lorenz Quack

> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the 
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did 
> not respond in time. It might be that the client JVM was garbage collecting 
> and did not execute anything which resulted in a timeout, it might be a 
> network issue, and finally it also might be the server not responding in a 
> timely fashion.
> The error message should be clarified to more clearly express the actual 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out

[ASF subversion and git services (JIRA)]

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

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

Commit 83dd606e3ce9e035f551f004ada071336f3efb65 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=83dd606 ]

QPID-8018: [Java Client, AMQP 0-x] Clarify error message when connection times 
out.


> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the 
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did 
> not respond in time. It might be that the client JVM was garbage collecting 
> and did not execute anything which resulted in a timeout, it might be a 
> network issue, and finally it also might be the server not responding in a 
> timely fashion.
> The error message should be clarified to more clearly express the actual 
> problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (PROTON-1682) SASL auth with GSSAPI fails: hostname is not set

[Alan Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244267#comment-16244267
 ] 

Alan Conway edited comment on PROTON-1682 at 11/8/17 4:29 PM:
--

I vote for passing the transport to the proactor. Anything else involves 
extensions to the event handling model that might have reprecussions elsewhere. 
We will see similar issues for SSL. 

The common pattern for bindings then becomes: 
1. configure C pn_transport and pn_connection  - using binding options from 
connect(), listener.on_accept() and container
2. start IO and event processing - C/C++ uses  proactor, ruby/go use 
connection_driver + native IO.
3. handle events - common C event set for all bindings, presented in 
binding-specific way as methods. virtual calls etc.

I think it was my mistake to hide transport configuration in the proactor - it 
is a good idea for the bindings to merge the connection/transport concepts but 
it was premature to try to do it at the C level where we still have a clear 
separation of connection/transport configuration for security and vhost.


was (Author: aconway):
I vote for passing the transport to the proactor. Anything else involves 
extensions to the event handling model that might have reprecussions elsewhere. 
We will see similar issues for SASL. 

The common pattern for bindings then becomes: 
1. configure C pn_transport and pn_connection  - using binding options from 
connect(), listener.on_accept() and container
2. start IO and event processing - C/C++ uses  proactor, ruby/go use 
connection_driver + native IO.
3. handle events - common C event set for all bindings, presented in 
binding-specific way as methods. virtual calls etc.

I think it was my mistake to hide transport configuration in the proactor - it 
is a good idea for the bindings to merge the connection/transport concepts but 
it was premature to try to do it at the C level where we still have a clear 
separation of connection/transport configuration for security and vhost.

> SASL auth with GSSAPI fails: hostname is not set
> 
>
> Key: PROTON-1682
> URL: https://issues.apache.org/jira/browse/PROTON-1682
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.18.1
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
> Fix For: proton-c-0.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (QPID-8024) [Broker-J] Reflect missing components and changes in copyright dates in the NOTICE file

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8024.
--
Resolution: Fixed

> [Broker-J] Reflect missing components and changes in copyright dates in the 
> NOTICE file
> ---
>
> Key: QPID-8024
> URL: https://issues.apache.org/jira/browse/QPID-8024
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Some of components are not enumerated in the NOTICE file and some of the 
> copyright date ranges are stale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8017:
-
Description: 
Reproduction:

* Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
{{com.sleepycat.je.*}} with Level.ALL
* Add a BDB HA VHN/VHN
* Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
logging only

For instance, JE writes the following message at {{FINE}} which should be 
logged by the handler as {{TRACE}}  but it is absent.

{noformat}
2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
[default] Clean file none: predicted min util is below minUtilization, current 
util min: 20 max: 20, predicted util min: 20 max: 20
{noformat}

There is a workaround for the functional problem, albeit a restart is required 
and the ability to change the process's system properties.  Use the normal JUL 
system property {{java.util.logging.config.file}}.  Set this to the location of 
a logging.properties file with the {{com.sleepycat.je}} logger set to the 
desired level.  Once the JVM is restarted, the Broker's log files will include 
the logging.

  was:
Reproduction:

* Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
{{com.sleepycat.je.*}} with Level.ALL
* Add a BDB HA VHN/VHN
* Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
logging only

For instance, JE writes the following message at {{FINE}} which should be 
logged by the handler as {{TRACE}}  but it is absent.

{noformat}
2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
[default] Clean file none: predicted min util is below minUtilization, current 
util min: 20 max: 20, predicted util min: 20 max: 20
{noformat}


There is a workaround for the problem, using the traditional JUL system 
property {{java.util.logging.config.file}}.  Set this to the location of a 
logging.properties file with the 


> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the functional problem, albeit a restart is 
> required and the ability to change the process's system properties.  Use the 
> normal JUL system property {{java.util.logging.config.file}}.  Set this to 
> the location of a logging.properties file with the {{com.sleepycat.je}} 
> logger set to the desired level.  Once the JVM is restarted, the Broker's log 
> files will include the logging.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8017:
-
Description: 
Reproduction:

* Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
{{com.sleepycat.je.*}} with Level.ALL
* Add a BDB HA VHN/VHN
* Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
logging only

For instance, JE writes the following message at {{FINE}} which should be 
logged by the handler as {{TRACE}}  but it is absent.

{noformat}
2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
[default] Clean file none: predicted min util is below minUtilization, current 
util min: 20 max: 20, predicted util min: 20 max: 20
{noformat}


There is a workaround for the problem, using the traditional JUL system 
property {{java.util.logging.config.file}}.  Set this to the location of a 
logging.properties file with the 

  was:

Reproduction:

* Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
{{com.sleepycat.je.*}} with Level.ALL
* Add a BDB HA VHN/VHN
* Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
logging only

For instance, JE writes the following message at {{FINE}} which should be 
logged by the handler as {{TRACE}}  but it is absent.

{noformat}
2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
[default] Clean file none: predicted min util is below minUtilization, current 
util min: 20 max: 20, predicted util min: 20 max: 20
{noformat}


> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the problem, using the traditional JUL system 
> property {{java.util.logging.config.file}}.  Set this to the location of a 
> logging.properties file with the 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1682) SASL auth with GSSAPI fails: hostname is not set

[Alan Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244267#comment-16244267
 ] 

Alan Conway commented on PROTON-1682:
-

I vote for passing the transport to the proactor. Anything else involves 
extensions to the event handling model that might have reprecussions elsewhere. 
We will see similar issues for SASL. 

The common pattern for bindings then becomes: 
1. configure C pn_transport and pn_connection  - using binding options from 
connect(), listener.on_accept() and container
2. start IO and event processing - C/C++ uses  proactor, ruby/go use 
connection_driver + native IO.
3. handle events - common C event set for all bindings, presented in 
binding-specific way as methods. virtual calls etc.

I think it was my mistake to hide transport configuration in the proactor - it 
is a good idea for the bindings to merge the connection/transport concepts but 
it was premature to try to do it at the C level where we still have a clear 
separation of connection/transport configuration for security and vhost.

> SASL auth with GSSAPI fails: hostname is not set
> 
>
> Key: PROTON-1682
> URL: https://issues.apache.org/jira/browse/PROTON-1682
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.18.1
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
> Fix For: proton-c-0.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1064) ruby: native IO based on connection_driver.c

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244218#comment-16244218
 ] 

ASF subversion and git services commented on PROTON-1064:
-

Commit 4856b6e1816ad3be4dc9fb06289701a1835aa7a9 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4856b6e ]

PROTON-1064: [ruby] New Container with native ruby IO

Minor doc correction, modify Container initialize parameters to match C++.


> ruby: native IO based on connection_driver.c 
> -
>
> Key: PROTON-1064
> URL: https://issues.apache.org/jira/browse/PROTON-1064
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Affects Versions: 0.11.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0
>
>
> Refactor ruby binding to use a native Ruby IO driver with the C 
> pn_connection_driver for AMQP protocol support. 
> Ruby ConnectionDriver - drive a single connection, single threaded
> - Use any ruby IO subclass
> - Works with native Ruby polling primitives
> - Avoids Ruby threading issue with GVL (all IO is done in Ruby) 
> - Thread safe function injection for MT use.
> Client/server examples using native ruby connect,  multi-threaded broker 
> example using ruby listen. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8020) [Broker-J] Rename binary and source distribution bundles for broker-j

[ASF subversion and git services (JIRA)]

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

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

Commit 588c1b2ac2d80b5a53578077429b042f6dcecf76 in qpid-broker-j's branch 
refs/heads/7.0.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=588c1b2 ]

QPID-8020: [Broker-J] Rename binary and source distribution bundles for broker-j

(cherry picked from commit 6d1fe661a6e5feaac49b3a51009541d78d9b138d)


> [Broker-J] Rename binary and source distribution bundles for broker-j
> -
>
> Key: QPID-8020
> URL: https://issues.apache.org/jira/browse/QPID-8020
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Binary and source distribution bundles for broker-j starts with 
> "qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
> for Java" into Broker-J. We should rename bundles to have distribution 
> bundles consistently named as distribution bundles for other qpid project 
> components.
> The source bundle name should be named as 
> apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
> the source bundle should be renamed as well to match bundle name 
> (apache-qpid-broker-j-$\{project.version\}-src).
> The binary bundles should be renamed into 
> apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
> apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the 
> binary bundles should not be changed( i.e, the root bundle folder should 
> remain to be 'qpid-broker' and it should contain a sub-folder having the same 
> name as version of distribution)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8023) [Broker-J] Remove com.google.code.findbugs:jsr305 dependency

[ASF subversion and git services (JIRA)]

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

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

Commit 8f7b3480697c96bafdf3188426461a1c7537fb5b in qpid-broker-j's branch 
refs/heads/7.0.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8f7b348 ]

QPID-8023: [Broker-J] Remove com.google.code.findbugs:jsr305 dependency

(cherry picked from commit 3943978d04d0f971360e2c98aff0bfdbab897938)


> [Broker-J] Remove com.google.code.findbugs:jsr305 dependency
> 
>
> Key: QPID-8023
> URL: https://issues.apache.org/jira/browse/QPID-8023
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The update of Google Guava (QPID-7864) added a dependency on 
> com.google.code.findbugs:jsr305.  This is not required and should be excluded 
> from the Broker's distribution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8024) [Broker-J] Reflect missing components and changes in copyright dates in the NOTICE file

[ASF subversion and git services (JIRA)]

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

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

Commit ecb83b04cf4a537dcdb28b885f17ea5fb4369d7d in qpid-broker-j's branch 
refs/heads/7.0.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ecb83b0 ]

QPID-8024: [Broker-J] Update NOTICE files

(cherry picked from commit 8e070efb00e6c2131f95ad77d2b5767d666a02b9)


> [Broker-J] Reflect missing components and changes in copyright dates in the 
> NOTICE file
> ---
>
> Key: QPID-8024
> URL: https://issues.apache.org/jira/browse/QPID-8024
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Some of components are not enumerated in the NOTICE file and some of the 
> copyright date ranges are stale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8023) [Broker-J] Remove com.google.code.findbugs:jsr305 dependency

[ASF subversion and git services (JIRA)]

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

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

Commit 3943978d04d0f971360e2c98aff0bfdbab897938 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3943978 ]

QPID-8023: [Broker-J] Remove com.google.code.findbugs:jsr305 dependency


> [Broker-J] Remove com.google.code.findbugs:jsr305 dependency
> 
>
> Key: QPID-8023
> URL: https://issues.apache.org/jira/browse/QPID-8023
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The update of Google Guava (QPID-7864) added a dependency on 
> com.google.code.findbugs:jsr305.  This is not required and should be excluded 
> from the Broker's distribution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8024) [Broker-J] Reflect missing components and changes in copyright dates in the NOTICE file

[ASF subversion and git services (JIRA)]

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

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

Commit 8e070efb00e6c2131f95ad77d2b5767d666a02b9 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8e070ef ]

QPID-8024: [Broker-J] Update NOTICE files


> [Broker-J] Reflect missing components and changes in copyright dates in the 
> NOTICE file
> ---
>
> Key: QPID-8024
> URL: https://issues.apache.org/jira/browse/QPID-8024
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Some of components are not enumerated in the NOTICE file and some of the 
> copyright date ranges are stale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8024) [Broker-J] Reflect missing components and changes in copyright dates in the NOTICE file

[Keith Wall (JIRA)]

Keith Wall created QPID-8024:


 Summary: [Broker-J] Reflect missing components and changes in 
copyright dates in the NOTICE file
 Key: QPID-8024
 URL: https://issues.apache.org/jira/browse/QPID-8024
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.0.0


Some of components are not enumerated in the NOTICE file and some of the 
copyright date ranges are stale.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8023) [Broker-J] Remove com.google.code.findbugs:jsr305 dependency

[Keith Wall (JIRA)]

Keith Wall created QPID-8023:


 Summary: [Broker-J] Remove com.google.code.findbugs:jsr305 
dependency
 Key: QPID-8023
 URL: https://issues.apache.org/jira/browse/QPID-8023
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.0.0


The update of Google Guava (QPID-7864) added a dependency on 
com.google.code.findbugs:jsr305.  This is not required and should be excluded 
from the Broker's distribution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8017:
--

I did, I don't think it helps.  The Broker's uses 
{{ch.qos.logback.core.filter.Filters}} rather than configuring the actual 
Loggers' levels.

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-8017:


Have you looked at 
[LevelChangePropagator|https://logback.qos.ch/manual/configuration.html#LevelChangePropagator]?

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8017 at 11/8/17 2:59 PM:
---

The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{$\{JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm own 
each config change would look like this:

{code}
foreach registered JUL loggers available from 
java.util.logging.LogManager#getLoggerNames
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.


was (Author: k-wall):
The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{\${JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm would 
look like this:

{code}
foreach registered JUL loggers { java.util.logging.LogManager#getLoggerNames}}
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, 

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ASF subversion and git services (JIRA)]

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

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

Commit 74cecc7d115fdf9f6a0a241efcbb0185cec73f71 in qpid-dispatch's branch 
refs/heads/1.0.x from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=74cecc7 ]

DISPATCH-767 - Minor fix to qdr_deliver_continue_peers_CT. Activate the 
connection if the work is processing


> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8017:
--

The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{${JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm would 
look like this:

{code}
foreach registered JUL loggers { java.util.logging.LogManager#getLoggerNames}}
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8017 at 11/8/17 2:52 PM:
---

The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{\${JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm would 
look like this:

{code}
foreach registered JUL loggers { java.util.logging.LogManager#getLoggerNames}}
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.


was (Author: k-wall):
The reason the JUL logging events that have severity lower than INFO emitted 
from JE are not included in the broker's log is that the JUL 
{{java.util.logging.Logger#isLoggable#isLoggable()}} which considers only 
{{java.util.logging.Logger#levelValue}}.  It does not consult the JUL handlers, 
so Broker's J logger providers never get to get a call.  The INFO default comes 
from the JVM {{${JAVA_HOME}/jre/lib/logging.properties}}

I suspect the change I suggested above would have unacceptable performance 
implications.  The JE implementation takes care to guard detailed logging 
statements but the effect of the change would be to make the 
{{logger.isLoggable(logLevel)}} guards return true, making the cost of the 
construction of the log message is paid even if logging is turned off.

For a general purpose solution the only solution I see is reflecting the logger 
configuration from the Broker/VirtualHostLogger world into the JUL world every 
time there is configuration change (or on first start-up).  The algorithm would 
look like this:

{code}
foreach registered JUL loggers { java.util.logging.LogManager#getLoggerNames}}
{
   Get the SLF4J logger for the registered JUL logger name
   // Test the logging level configured on the SLF4J logger and reflect on to 
the JUL logger e.g.
if (SLF4JLogger.isDebugEnabled())
{ 
JULLogger.setLevel(convertSLF4JToJULLevel(DEBUG));
} 
else if (SLF4JLogger.isInfoEnabled())
{
 
}
}
{code}

This would be general purpose code and would not need to know about JE.   If 
Qpid integrated any other component using JUL logging, this approach would work 
unchanged.

> [Broker-J] [BDB]  JE log events written at JUL level FINE and below not 
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source 
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour:  verbose logging from JE.  Actual behaviour:  moderate 
> logging only
> For instance, JE writes the following message at {{FINE}} which should be 
> logged by the handler as {{TRACE}}  but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - 
> [default] Clean file none: predicted min util is below minUtilization, 
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: 

[jira] [Assigned] (QPID-7897) [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously first converts to string before retreiving bytes

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-7897:
--

Assignee: Lorenz Quack

> [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously 
> first converts to string before retreiving bytes 
> 
>
> Key: QPID-7897
> URL: https://issues.apache.org/jira/browse/QPID-7897
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> If the correlationId of a message does not contain valid UTF_8 (e.g., set via 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}}) then 
> {{javax.jms.Message#getJMSCorrelationIDAsBytes}} does not return the correct 
> value.
> Some relevant code 
> snippets:{{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} is implemented 
> as follows:
> {code:title=AMQMessageDelegate_0_8.java}public byte[] 
> getJMSCorrelationIDAsBytes() throws JMSException
> {
> return getContentHeaderProperties().getCorrelationIdAsString().getBytes();
> }{code}
> {code:title=BasicContentHeaderProperties}public String 
> getCorrelationIdAsString()
> {
> return (_correlationId == null) ? null : _correlationId.toString();
> }{code}
> {code:title=AMQShortString}public String toString()
> {
> if (_asString == null)
> {
> _asString = new String(_data, _offset, _length, 
> StandardCharsets.UTF_8);
> }
> return _asString;
> }{code}
> If {{_data}} does not contain valid UTF_8 the result of this call chain is 
> incorrect.
> I do not see a reason why 
> {{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} should not return 
> {{getContentHeaderProperties().getCorrelationId().getBytes()}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-7899:
--

Assignee: Lorenz Quack

> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously 
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new 
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding 
> (in which case why would you use this method in the first place), this is 
> wrong.
> In the JMS API implementation of  
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and 
> it explicitly allows the provider to throw 
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw 
> {{UnsupportedOperationException}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7897) [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously first converts to string before retreiving bytes

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7897:
---
Status: Reviewable  (was: In Progress)

> [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously 
> first converts to string before retreiving bytes 
> 
>
> Key: QPID-7897
> URL: https://issues.apache.org/jira/browse/QPID-7897
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> If the correlationId of a message does not contain valid UTF_8 (e.g., set via 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}}) then 
> {{javax.jms.Message#getJMSCorrelationIDAsBytes}} does not return the correct 
> value.
> Some relevant code 
> snippets:{{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} is implemented 
> as follows:
> {code:title=AMQMessageDelegate_0_8.java}public byte[] 
> getJMSCorrelationIDAsBytes() throws JMSException
> {
> return getContentHeaderProperties().getCorrelationIdAsString().getBytes();
> }{code}
> {code:title=BasicContentHeaderProperties}public String 
> getCorrelationIdAsString()
> {
> return (_correlationId == null) ? null : _correlationId.toString();
> }{code}
> {code:title=AMQShortString}public String toString()
> {
> if (_asString == null)
> {
> _asString = new String(_data, _offset, _length, 
> StandardCharsets.UTF_8);
> }
> return _asString;
> }{code}
> If {{_data}} does not contain valid UTF_8 the result of this call chain is 
> incorrect.
> I do not see a reason why 
> {{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} should not return 
> {{getContentHeaderProperties().getCorrelationId().getBytes()}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-7899:
--

Assignee: (was: Lorenz Quack)

> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously 
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new 
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding 
> (in which case why would you use this method in the first place), this is 
> wrong.
> In the JMS API implementation of  
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and 
> it explicitly allows the provider to throw 
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw 
> {{UnsupportedOperationException}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7899:
---
Status: Reviewable  (was: In Progress)

> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously 
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new 
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding 
> (in which case why would you use this method in the first place), this is 
> wrong.
> In the JMS API implementation of  
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and 
> it explicitly allows the provider to throw 
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw 
> {{UnsupportedOperationException}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string

[ASF subversion and git services (JIRA)]

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

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

Commit 8774a1c38d596e17683aac1a285ec437d82c7767 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=8774a1c ]

QPID-7897, QPID-7899: [Java Client, AMQP 0-x] Do not convert to/from String in 
Message#set-/getJMSCorrelationIDAsBytes()


> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously 
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new 
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding 
> (in which case why would you use this method in the first place), this is 
> wrong.
> In the JMS API implementation of  
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and 
> it explicitly allows the provider to throw 
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw 
> {{UnsupportedOperationException}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-767 - Minor fix to qdr_deliver_continue_peers_CT. Activate the 
connection if the work is processing


> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7897) [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously first converts to string before retreiving bytes

[ASF subversion and git services (JIRA)]

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

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

Commit 8774a1c38d596e17683aac1a285ec437d82c7767 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=8774a1c ]

QPID-7897, QPID-7899: [Java Client, AMQP 0-x] Do not convert to/from String in 
Message#set-/getJMSCorrelationIDAsBytes()


> [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously 
> first converts to string before retreiving bytes 
> 
>
> Key: QPID-7897
> URL: https://issues.apache.org/jira/browse/QPID-7897
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> If the correlationId of a message does not contain valid UTF_8 (e.g., set via 
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}}) then 
> {{javax.jms.Message#getJMSCorrelationIDAsBytes}} does not return the correct 
> value.
> Some relevant code 
> snippets:{{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} is implemented 
> as follows:
> {code:title=AMQMessageDelegate_0_8.java}public byte[] 
> getJMSCorrelationIDAsBytes() throws JMSException
> {
> return getContentHeaderProperties().getCorrelationIdAsString().getBytes();
> }{code}
> {code:title=BasicContentHeaderProperties}public String 
> getCorrelationIdAsString()
> {
> return (_correlationId == null) ? null : _correlationId.toString();
> }{code}
> {code:title=AMQShortString}public String toString()
> {
> if (_asString == null)
> {
> _asString = new String(_data, _offset, _length, 
> StandardCharsets.UTF_8);
> }
> return _asString;
> }{code}
> If {{_data}} does not contain valid UTF_8 the result of this call chain is 
> incorrect.
> I do not see a reason why 
> {{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} should not return 
> {{getContentHeaderProperties().getCorrelationId().getBytes()}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8020) [Broker-J] Rename binary and source distribution bundles for broker-j

[ASF subversion and git services (JIRA)]

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

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

Commit 6d1fe661a6e5feaac49b3a51009541d78d9b138d in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6d1fe66 ]

QPID-8020: [Broker-J] Rename binary and source distribution bundles for broker-j


> [Broker-J] Rename binary and source distribution bundles for broker-j
> -
>
> Key: QPID-8020
> URL: https://issues.apache.org/jira/browse/QPID-8020
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Binary and source distribution bundles for broker-j starts with 
> "qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
> for Java" into Broker-J. We should rename bundles to have distribution 
> bundles consistently named as distribution bundles for other qpid project 
> components.
> The source bundle name should be named as 
> apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
> the source bundle should be renamed as well to match bundle name 
> (apache-qpid-broker-j-$\{project.version\}-src).
> The binary bundles should be renamed into 
> apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
> apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the 
> binary bundles should not be changed( i.e, the root bundle folder should 
> remain to be 'qpid-broker' and it should contain a sub-folder having the same 
> name as version of distribution)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes

[Alan Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243963#comment-16243963
 ] 

Alan Conway commented on PROTON-1537:
-

Currently there is a new Qpid::Proton::Container class, which is similar to the 
Qpid::Proton::Reactor::Container but has minor API differences.
The next step will be to move towards the common API model outlined in 
http://home.apache.org/~jross/pumpjack/index.html  and implemented in the C++ 
binding, while retaining compatiblity for older applications, via some 
combination of:

- staying close to the old API where that does not distort the new model
- adding new methods/classes and deprecating old ones
- making multi-use methods that can be called with new or old style parameters


> ruby: update API in line with new C++ API changes
> -
>
> Key: PROTON-1537
> URL: https://issues.apache.org/jira/browse/PROTON-1537
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0
>
>
> Update the ruby Container interface in line with the new C++ container API
> Deprecate Reactor (use Container instead)
> Deprecate or remove Messenger API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7964:
---
Status: Reviewable  (was: In Progress)

> [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and 
> "," for passwords
> ---
>
> Key: QPID-7964
> URL: https://issues.apache.org/jira/browse/QPID-7964
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" 
> and "," in passwords when using the SCRAM SASL mechanism.
> This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires 
> encoding of those characters for the username. Not for the password.
> This was reported on the [user mailing 
> list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-7964:
--

Assignee: Lorenz Quack

> [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and 
> "," for passwords
> ---
>
> Key: QPID-7964
> URL: https://issues.apache.org/jira/browse/QPID-7964
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" 
> and "," in passwords when using the SCRAM SASL mechanism.
> This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires 
> encoding of those characters for the username. Not for the password.
> This was reported on the [user mailing 
> list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-7964:
--

Assignee: (was: Lorenz Quack)

> [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and 
> "," for passwords
> ---
>
> Key: QPID-7964
> URL: https://issues.apache.org/jira/browse/QPID-7964
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" 
> and "," in passwords when using the SCRAM SASL mechanism.
> This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires 
> encoding of those characters for the username. Not for the password.
> This was reported on the [user mailing 
> list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7964:


The fix and tests were adapted from QPIDJMS-335

> [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and 
> "," for passwords
> ---
>
> Key: QPID-7964
> URL: https://issues.apache.org/jira/browse/QPID-7964
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" 
> and "," in passwords when using the SCRAM SASL mechanism.
> This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires 
> encoding of those characters for the username. Not for the password.
> This was reported on the [user mailing 
> list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords

[ASF subversion and git services (JIRA)]

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

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

Commit 1043d0f4de9539b7a861cebcc3925c4acf13a431 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=1043d0f ]

QPID-7964: [Java Client, AMQP 0-x] In SCRAM SASL implementation do not 
incorrectly encode "=" and "," for passwords


> [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and 
> "," for passwords
> ---
>
> Key: QPID-7964
> URL: https://issues.apache.org/jira/browse/QPID-7964
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" 
> and "," in passwords when using the SCRAM SASL mechanism.
> This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires 
> encoding of those characters for the username. Not for the password.
> This was reported on the [user mailing 
> list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1017) Engine does not handle UNINITIALIZED/CLOSED sessions

[JIRA]

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

Jiri Daněk updated PROTON-1017:
---
Summary: Engine does not handle UNINITIALIZED/CLOSED sessions  (was: Engine 
does not handle UNINITALIZED/CLOSED sessions)

> Engine does not handle UNINITIALIZED/CLOSED sessions
> 
>
> Key: PROTON-1017
> URL: https://issues.apache.org/jira/browse/PROTON-1017
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.10
>Reporter: Bozo Dragojevic
>  Labels: patch
> Fix For: proton-j-future
>
> Attachments: PROTON-1017-WIP.patch
>
>
> If the initiator sends a BEGIN and END frame the receiving engine processed 
> the END frame before generating the outgoing BEGIN frame and it has no notion 
> of remoteChannel number anymore.
> {noformat}
> [2114881339:0] -> Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1472159463:0] <- Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1472159463:0] -> Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [2114881339:0] <- Open{ containerId='', hostname='', maxFrameSize=4294967295, 
> channelMax=65535, idleTimeOut=null, outgoingLocales=null, 
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [2114881339:0] -> Begin{remoteChannel=null, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [2114881339:0] -> End{error=null}
> [1472159463:0] <- Begin{remoteChannel=null, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1472159463:0] <- End{error=null}
> [1472159463:0] -> Begin{remoteChannel=65535, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1472159463:0] -> End{error=null}
> [2114881339:0] <- Begin{remoteChannel=65535, nextOutgoingId=1, 
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> {noformat}
> test dies with
> {noformat}
> java.lang.NullPointerException: uncorrelated channel: 65535
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.handleBegin(TransportImpl.java:1074)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.handleBegin(TransportImpl.java:1)
>   at org.apache.qpid.proton.amqp.transport.Begin.invoke(Begin.java:144)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.handleFrame(TransportImpl.java:1304)
>   at 
> org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:419)
>   at 
> org.apache.qpid.proton.engine.impl.FrameParser.process(FrameParser.java:528)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.process(TransportImpl.java:1415)
>   at 
> org.apache.qpid.proton.engine.impl.TransportImpl.processInput(TransportImpl.java:1373)
>   at 
> org.apache.qpid.proton.systemtests.EngineTestBase.pumpServerToClient(EngineTestBase.java:73)
>   at 
> org.apache.qpid.proton.systemtests.ProtonEngineExampleTest.testPROTON_TBD(ProtonEngineExampleTest.java:350)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7947) [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames

[ASF subversion and git services (JIRA)]

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

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

Commit 92535ae3de7178008f70bac94adb8155eeba3848 in qpid-broker-j's branch 
refs/heads/6.1.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=92535ae ]

QPID-7947: [Broker-J] Improve frame handling

Merged by hand from master 66cef783f63ceb0252fbf236ae0577aa5e14b23d


> [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames
> ---
>
> Key: QPID-7947
> URL: https://issues.apache.org/jira/browse/QPID-7947
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0, qpid-java-6.1.5
>
>
> Empty frames should only be allowed for AMQP (and not SASL) transports.  
> Overlarge frames should be detected as soon as possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7947) [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7947:
-
Fix Version/s: qpid-java-6.1.5

> [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames
> ---
>
> Key: QPID-7947
> URL: https://issues.apache.org/jira/browse/QPID-7947
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0, qpid-java-6.1.5
>
>
> Empty frames should only be allowed for AMQP (and not SASL) transports.  
> Overlarge frames should be detected as soon as possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8022) [Broker-J, WMC] When the session ends (timeout, broker goes away, connection lost) the UI should cearly indicate this

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-8022:


One possibility would be to redirect to the login page directly and add the 
possibility to display an error there to indicate why the user ended up at the 
login page. For example 
* Failed login: Login failed. Try again.
* Authorization failed: Not authorized to log in to this broker. Try other 
credentials.
* Session timeout: Previous session timed out. Please re-authenticate by 
logging in again.
* Connection lost (could be broker crash): Connection to the broker was lost. 
Fix the problem and try logging in again.

> [Broker-J, WMC] When the session ends (timeout, broker goes away, connection 
> lost) the UI should cearly indicate this
> -
>
> Key: QPID-8022
> URL: https://issues.apache.org/jira/browse/QPID-8022
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>
> Currently when the http session ends (for example when the configured 
> {{qpid.port.http.absoluteSessionTimeout}} expires) the Web Management Console 
> (WMC) displays a  dialogue box (with a generic 401 error in this case) 
> offering a button to log in again.
> However, the dialogue box is closable. If the user closes it the WMC remains 
> somewhat usable. All client-side operations continue to work (e.g., create a 
> Query). Some operations fail silently (e.g., retrieving data when opening a 
> new tab by double clicking on, for example, a Port) and yet other operations 
> redisplay the 401 dialogue (e.g., broker-side operations involving POST or 
> PUT).
> I think when the user is no longer logged in the WMC should clearly indicate 
> this by  somehow preventing all further use of the WMC. From a security point 
> of view we also want the existing data currently being displayed to disappear.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8022) [Broker-J, WMC] When the session ends (timeout, broker goes away, connection lost) the UI should cearly indicate this

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-8022:
--

 Summary: [Broker-J, WMC] When the session ends (timeout, broker 
goes away, connection lost) the UI should cearly indicate this
 Key: QPID-8022
 URL: https://issues.apache.org/jira/browse/QPID-8022
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Lorenz Quack


Currently when the http session ends (for example when the configured 
{{qpid.port.http.absoluteSessionTimeout}} expires) the Web Management Console 
(WMC) displays a  dialogue box (with a generic 401 error in this case) offering 
a button to log in again.
However, the dialogue box is closable. If the user closes it the WMC remains 
somewhat usable. All client-side operations continue to work (e.g., create a 
Query). Some operations fail silently (e.g., retrieving data when opening a new 
tab by double clicking on, for example, a Port) and yet other operations 
redisplay the 401 dialogue (e.g., broker-side operations involving POST or PUT).

I think when the user is no longer logged in the WMC should clearly indicate 
this by  somehow preventing all further use of the WMC. From a security point 
of view we also want the existing data currently being displayed to disappear.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7853) Message enqueued twice to the same queue leads to Broker failure

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7853:
-
Status: Reviewable  (was: In Progress)

> Message enqueued twice to the same queue leads to Broker failure
> 
>
> Key: QPID-7853
> URL: https://issues.apache.org/jira/browse/QPID-7853
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-6.1.4
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1.5, qpid-java-6.0.9
>
>
> QPID-4307 added a defence against the same message being enqueued twice on a 
> single queue, however a defect at 
> {{org/apache/qpid/server/exchange/AbstractExchange.java:502}} means that it 
> is still possible for this situation to arise on some paths.
> Reproduction:
> # Create queue with DLQ wired-up and max delivery count enforced.
> # Publish a single message to the queue.
> # Use management to copy the message from the queue to the DLQ
> # Transactionally consume the message and rollback until the message is 
> dead-lettered..
> The following stack trace will appear and the Broker will shutdown.
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java 
> -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:61800,suspend=y,server=n 
> -DQPID_HOME=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT
>  
> -DQPID_WORK=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT/work
>  -DSSL_DIR=/Users/keith/src/qpid-broker-j/test-profiles/test_resources/ssl/ 
> -Xmx4g -DXqpid.httpManagement.serveUncompressedDojo=true 
> -DXqpid.broker.networkBufferSize=1046512 -Djavax.net.debugX=ssl 
> -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Assigned] (QPID-7853) Message enqueued twice to the same queue leads to Broker failure

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-7853:


Assignee: Keith Wall

> Message enqueued twice to the same queue leads to Broker failure
> 
>
> Key: QPID-7853
> URL: https://issues.apache.org/jira/browse/QPID-7853
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-6.1.4
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1.5, qpid-java-6.0.9
>
>
> QPID-4307 added a defence against the same message being enqueued twice on a 
> single queue, however a defect at 
> {{org/apache/qpid/server/exchange/AbstractExchange.java:502}} means that it 
> is still possible for this situation to arise on some paths.
> Reproduction:
> # Create queue with DLQ wired-up and max delivery count enforced.
> # Publish a single message to the queue.
> # Use management to copy the message from the queue to the DLQ
> # Transactionally consume the message and rollback until the message is 
> dead-lettered..
> The following stack trace will appear and the Broker will shutdown.
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java 
> -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:61800,suspend=y,server=n 
> -DQPID_HOME=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT
>  
> -DQPID_WORK=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT/work
>  -DSSL_DIR=/Users/keith/src/qpid-broker-j/test-profiles/test_resources/ssl/ 
> -Xmx4g -DXqpid.httpManagement.serveUncompressedDojo=true 
> -DXqpid.broker.networkBufferSize=1046512 -Djavax.net.debugX=ssl 
> -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Commented] (QPID-7853) Message enqueued twice to the same queue leads to Broker failure

[ASF subversion and git services (JIRA)]

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

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

Commit e7ed8e9fb170b9e291a52ea9ef06f3dfa6555a74 in qpid-broker-j's branch 
refs/heads/6.0.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=e7ed8e9 ]

QPID-7853: [Broker-J] Avoid possibility that a message is enqueue twice to the 
same queue.

Cherry picked from 6.1.x 11b691ba1699b063b3e3cbbcaa62b5b7b48aa468


> Message enqueued twice to the same queue leads to Broker failure
> 
>
> Key: QPID-7853
> URL: https://issues.apache.org/jira/browse/QPID-7853
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-6.1.4
>Reporter: Keith Wall
> Fix For: qpid-java-6.1.5, qpid-java-6.0.9
>
>
> QPID-4307 added a defence against the same message being enqueued twice on a 
> single queue, however a defect at 
> {{org/apache/qpid/server/exchange/AbstractExchange.java:502}} means that it 
> is still possible for this situation to arise on some paths.
> Reproduction:
> # Create queue with DLQ wired-up and max delivery count enforced.
> # Publish a single message to the queue.
> # Use management to copy the message from the queue to the DLQ
> # Transactionally consume the message and rollback until the message is 
> dead-lettered..
> The following stack trace will appear and the Broker will shutdown.
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java 
> -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:61800,suspend=y,server=n 
> -DQPID_HOME=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT
>  
> -DQPID_WORK=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT/work
>  -DSSL_DIR=/Users/keith/src/qpid-broker-j/test-profiles/test_resources/ssl/ 
> -Xmx4g -DXqpid.httpManagement.serveUncompressedDojo=true 
> -DXqpid.broker.networkBufferSize=1046512 -Djavax.net.debugX=ssl 
> -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Commented] (QPID-7853) Message enqueued twice to the same queue leads to Broker failure

[ASF subversion and git services (JIRA)]

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

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

Commit 11b691ba1699b063b3e3cbbcaa62b5b7b48aa468 in qpid-broker-j's branch 
refs/heads/6.1.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=11b691b ]

QPID-7853: [Broker-J] Avoid possibility that a message is enqueue twice to the 
same queue.


> Message enqueued twice to the same queue leads to Broker failure
> 
>
> Key: QPID-7853
> URL: https://issues.apache.org/jira/browse/QPID-7853
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-6.1.4
>Reporter: Keith Wall
> Fix For: qpid-java-6.1.5, qpid-java-6.0.9
>
>
> QPID-4307 added a defence against the same message being enqueued twice on a 
> single queue, however a defect at 
> {{org/apache/qpid/server/exchange/AbstractExchange.java:502}} means that it 
> is still possible for this situation to arise on some paths.
> Reproduction:
> # Create queue with DLQ wired-up and max delivery count enforced.
> # Publish a single message to the queue.
> # Use management to copy the message from the queue to the DLQ
> # Transactionally consume the message and rollback until the message is 
> dead-lettered..
> The following stack trace will appear and the Broker will shutdown.
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java 
> -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:61800,suspend=y,server=n 
> -DQPID_HOME=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT
>  
> -DQPID_WORK=/Users/keith/src/qpid-broker-j/systests/target/qpid-broker/6.1.5-SNAPSHOT/work
>  -DSSL_DIR=/Users/keith/src/qpid-broker-j/test-profiles/test_resources/ssl/ 
> -Xmx4g -DXqpid.httpManagement.serveUncompressedDojo=true 
> -DXqpid.broker.networkBufferSize=1046512 -Djavax.net.debugX=ssl 
> -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Updated] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7973:
-
Fix Version/s: qpid-java-6.1.5

> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0, qpid-java-6.1.5
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7974:
-
Fix Version/s: qpid-java-6.1.5

> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0, qpid-java-6.1.5
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[ASF subversion and git services (JIRA)]

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

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

Commit 94dd1bb2712c0af989030f38728c3ca095bd64fc in qpid-broker-j's branch 
refs/heads/6.1.x from [~godfrer]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=94dd1bb ]

QPID-7974 : Fix the logic I broker in Adel's commit

Cherry picked from master 955a79b7dfde570dc7d7a6cc9d89b2e6dd1ff137


> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8020) [Broker-J] Rename binary and source distribution bundles for broker-j

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8020:
-
Description: 
Binary and source distribution bundles for broker-j starts with 
"qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
for Java" into Broker-J. We should rename bundles to have distribution bundles 
consistently named as distribution bundles for other qpid project components.

The source bundle name should be named as 
apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
the source bundle should be renamed as well to match bundle name 
(apacher-qpid-broker-j-$\{project.version\}-src).

The binary bundles should be renamed into 
apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the binary 
bundles should not be changed( i.e, the root bundle folder should remain to be 
'qpid-broker' and it should contain a sub-folder having the same name as 
version of distribution)

  was:
Binary and source distribution bundles for broker-j starts with 
"qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
for Java" into Broker-J. We should rename bundles to have distribution bundles 
consistently named as distribution bundles for other qpid project components.

The source bundle name should be named as 
apacher-qpid-broker-j-$\{project.version\}-src.tar.gz. The  folder inside of 
the source bundle should be renamed as well to match bundle name 
(apacher-qpid-broker-j-$\{project.version\}-src).

The binary bundles should be renamed into 
apacher-qpid-broker-j-$\{project.version\}-bin.tar.gz and 
apacher-qpid-broker-j-$\{project.version\}-bin.zip. The structure of the binary 
bundles should not be changed( i.e, the root bundle folder should remain to be 
'qpid-broker' and it should contain a sub-folder having the same name as 
version of distribution)


> [Broker-J] Rename binary and source distribution bundles for broker-j
> -
>
> Key: QPID-8020
> URL: https://issues.apache.org/jira/browse/QPID-8020
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Binary and source distribution bundles for broker-j starts with 
> "qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
> for Java" into Broker-J. We should rename bundles to have distribution 
> bundles consistently named as distribution bundles for other qpid project 
> components.
> The source bundle name should be named as 
> apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
> the source bundle should be renamed as well to match bundle name 
> (apacher-qpid-broker-j-$\{project.version\}-src).
> The binary bundles should be renamed into 
> apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
> apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the 
> binary bundles should not be changed( i.e, the root bundle folder should 
> remain to be 'qpid-broker' and it should contain a sub-folder having the same 
> name as version of distribution)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle

[ASF subversion and git services (JIRA)]

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

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

Commit 696107df078c420394bed8594d8e50dfc283dc84 in qpid-broker-j's branch 
refs/heads/6.1.x from aboutros
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=696107d ]

QPID-7974: Only search for the needed table instead of querying the whole 
database tables
This closes #3

Cherry-picked from master 3a6bb20dc037a88d528045eae4bcc2daacf955ae


> JdbcUtils.TableExists is very slow on big databases such as Oracle
> --
>
> Key: QPID-7974
> URL: https://issues.apache.org/jira/browse/QPID-7974
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The problem is that JdbcUtils.tableExists will actually load all tables and 
> then iterate to find the correct one. On Oracle, this can be around 40 000 
> tables. So it will take 12 minutes for the broker to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8020) [Broker-J] Rename binary and source distribution bundles for broker-j

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8020:
-
Description: 
Binary and source distribution bundles for broker-j starts with 
"qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
for Java" into Broker-J. We should rename bundles to have distribution bundles 
consistently named as distribution bundles for other qpid project components.

The source bundle name should be named as 
apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
the source bundle should be renamed as well to match bundle name 
(apache-qpid-broker-j-$\{project.version\}-src).

The binary bundles should be renamed into 
apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the binary 
bundles should not be changed( i.e, the root bundle folder should remain to be 
'qpid-broker' and it should contain a sub-folder having the same name as 
version of distribution)

  was:
Binary and source distribution bundles for broker-j starts with 
"qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
for Java" into Broker-J. We should rename bundles to have distribution bundles 
consistently named as distribution bundles for other qpid project components.

The source bundle name should be named as 
apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
the source bundle should be renamed as well to match bundle name 
(apacher-qpid-broker-j-$\{project.version\}-src).

The binary bundles should be renamed into 
apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the binary 
bundles should not be changed( i.e, the root bundle folder should remain to be 
'qpid-broker' and it should contain a sub-folder having the same name as 
version of distribution)


> [Broker-J] Rename binary and source distribution bundles for broker-j
> -
>
> Key: QPID-8020
> URL: https://issues.apache.org/jira/browse/QPID-8020
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Binary and source distribution bundles for broker-j starts with 
> "qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
> for Java" into Broker-J. We should rename bundles to have distribution 
> bundles consistently named as distribution bundles for other qpid project 
> components.
> The source bundle name should be named as 
> apache-qpid-broker-j-$\{project.version\}\-src.tar.gz. The  folder inside of 
> the source bundle should be renamed as well to match bundle name 
> (apache-qpid-broker-j-$\{project.version\}-src).
> The binary bundles should be renamed into 
> apache-qpid-broker-j-$\{project.version\}\-bin.tar.gz and 
> apache-qpid-broker-j-$\{project.version\}\-bin.zip. The structure of the 
> binary bundles should not be changed( i.e, the root bundle folder should 
> remain to be 'qpid-broker' and it should contain a sub-folder having the same 
> name as version of distribution)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7973) Table Name Prefix is set to NULL if no prefix is provided instead of empty String

[ASF subversion and git services (JIRA)]

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

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

Commit 848a209b1279ddb7c0fdef495c91abc5cda48339 in qpid-broker-j's branch 
refs/heads/6.1.x from aboutros
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=848a209 ]

QPID-7973: Table Name Prefix is set to NULL if no prefix is provided instead of 
empty String
This closes #2

Cherry picked from master d68c897052ca3e7a07f7ca4fccfd1f4d6832b6d7


> Table Name Prefix is set to NULL if no prefix is provided instead of empty 
> String
> -
>
> Key: QPID-7973
> URL: https://issues.apache.org/jira/browse/QPID-7973
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.4
>Reporter: Adel Boutros
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> If the user provides no TableNamePrefix, then it is set to null whereas it 
> should be set to empty string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8020) [Broker-J] Rename binary and source distribution bundles for broker-j

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8020:
-
Description: 
Binary and source distribution bundles for broker-j starts with 
"qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
for Java" into Broker-J. We should rename bundles to have distribution bundles 
consistently named as distribution bundles for other qpid project components.

The source bundle name should be named as 
apacher-qpid-broker-j-$\{project.version\}-src.tar.gz. The  folder inside of 
the source bundle should be renamed as well to match bundle name 
(apacher-qpid-broker-j-$\{project.version\}-src).

The binary bundles should be renamed into 
apacher-qpid-broker-j-$\{project.version\}-bin.tar.gz and 
apacher-qpid-broker-j-$\{project.version\}-bin.zip. The structure of the binary 
bundles should not be changed( i.e, the root bundle folder should remain to be 
'qpid-broker' and it should contain a sub-folder having the same name as 
version of distribution)

  was:Binary and source distribution bundles for broker-j starts with 
"qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
for Java" into Broker-J. We should rename bundles to start with qpid-broker-j-. 
The source bundle name should be named as 
qpid-broker-j-$\{project.version\}-src. The  folder inside of the source bundle 
should be renamed as well.


> [Broker-J] Rename binary and source distribution bundles for broker-j
> -
>
> Key: QPID-8020
> URL: https://issues.apache.org/jira/browse/QPID-8020
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Binary and source distribution bundles for broker-j starts with 
> "qpid-java-broker-" which is not accurate any-more after renaming of "Broker 
> for Java" into Broker-J. We should rename bundles to have distribution 
> bundles consistently named as distribution bundles for other qpid project 
> components.
> The source bundle name should be named as 
> apacher-qpid-broker-j-$\{project.version\}-src.tar.gz. The  folder inside of 
> the source bundle should be renamed as well to match bundle name 
> (apacher-qpid-broker-j-$\{project.version\}-src).
> The binary bundles should be renamed into 
> apacher-qpid-broker-j-$\{project.version\}-bin.tar.gz and 
> apacher-qpid-broker-j-$\{project.version\}-bin.zip. The structure of the 
> binary bundles should not be changed( i.e, the root bundle folder should 
> remain to be 'qpid-broker' and it should contain a sub-folder having the same 
> name as version of distribution)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8021) [Broker-J] [BDB] Make BDB store module compatible with later JE releases [6.1.x]

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8021:
-
Description: 
There a couple of simple binary incompatibilities that prevent a user of Broker 
J 6.1.x from substituting a newer BDB JE releases.Adapting the code to 
allow the 6.1.5 release to work with the current newer releases  will give the 
user the option to upgrade if they wish (say to avoid a defect in BDB JE).

As Broker-J 6.1.x originally targeted JE 5.0.104 compatibility with this will 
be retained.


  was:Make BDB store module compatible with later JE releases


> [Broker-J] [BDB] Make BDB store module compatible with later JE releases 
> [6.1.x]
> 
>
> Key: QPID-8021
> URL: https://issues.apache.org/jira/browse/QPID-8021
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1.5
>
>
> There a couple of simple binary incompatibilities that prevent a user of 
> Broker J 6.1.x from substituting a newer BDB JE releases.Adapting the 
> code to allow the 6.1.5 release to work with the current newer releases  will 
> give the user the option to upgrade if they wish (say to avoid a defect in 
> BDB JE).
> As Broker-J 6.1.x originally targeted JE 5.0.104 compatibility with this will 
> be retained.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8021) [Broker-J] [BDB] Make BDB store module compatible with later JE releases [6.1.x]

[Keith Wall (JIRA)]

Keith Wall created QPID-8021:


 Summary: [Broker-J] [BDB] Make BDB store module compatible with 
later JE releases [6.1.x]
 Key: QPID-8021
 URL: https://issues.apache.org/jira/browse/QPID-8021
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-6.1.5


Make BDB store module compatible with later JE releases



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7725) Remove direct byte buffer implementation

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7725:
-
Fix Version/s: (was: Future)
   qpid-java-client-0-x-6.3.0

> Remove direct byte buffer implementation
> 
>
> Key: QPID-7725
> URL: https://issues.apache.org/jira/browse/QPID-7725
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Direct byte buffers were never used on the client, and now the client/broker 
> are separate, the code is unused.  It is unused and could be removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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