[jira] [Created] (QPID-6955) BufferOverflowException downloading message content

2015-12-16 Thread Mark Soderquist (JIRA) 
Mark Soderquist created QPID-6955:
-

 Summary: BufferOverflowException downloading message content
 Key: QPID-6955
 URL: https://issues.apache.org/jira/browse/QPID-6955
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.0
 Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
OpenJDK Runtime Environment (build 1.8.0_65-b17)
OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)

2015-12-16 13:32:09,111 INFO  [Broker-Config] (q.m.b.startup) - [Broker] 
BRK-1001 : Startup : Version: 6.0.0 Build: 1717754
2015-12-16 13:32:09,116 INFO  [Broker-Config] (q.m.b.platform) - [Broker] 
BRK-1010 : Platform : JVM : Oracle Corporation version: 1.8.0_65-b17 OS : Linux 
version: 2.6.32-573.8.1.el6.x86_64 arch: amd64 cores: 1
2015-12-16 13:32:09,118 INFO  [Broker-Config] (q.m.b.max_memory) - [Broker] 
BRK-1011 : Maximum Memory : Heap : 528,154,624 bytes Direct : 1,610,612,736 
bytes
Reporter: Mark Soderquist


Received the following exception when downloading message content from Qpid 
HTTP Manager:

2015-12-16 13:29:31,768 ERROR [HttpManagement-HTTPS-117] 
(o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
'/api/latest/queue/default/default/ext-zions-validation-mock/getMessageContent':
 
java.nio.BufferOverflowException: null
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:214) ~[na:1.8.0_65]
at 
org.apache.qpid.bytebuffer.QpidByteBuffer.copyTo(QpidByteBuffer.java:236) 
~[qpid-common-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.getContent(AbstractBDBMessageStore.java:1113)
 ~[qpid-bdbstore-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:178)
 ~[qpid-broker-core-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.queue.AbstractQueue$MessageContentFinder.visit(AbstractQueue.java:3445)
 ~[qpid-broker-core-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.queue.AbstractQueue.visit(AbstractQueue.java:1799) 
~[qpid-broker-core-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3349)
 ~[qpid-broker-core-6.0.0.jar:6.0.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[na:1.8.0_65]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[na:1.8.0_65]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[na:1.8.0_65]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_65]
at 
org.apache.qpid.server.model.ConfiguredObjectOperation.perform(ConfiguredObjectOperation.java:155)
 ~[qpid-broker-core-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:634)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGetWithSubjectAndActor(RestServlet.java:358)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet$1.run(AbstractServlet.java:90)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet$1.run(AbstractServlet.java:86)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at java.security.AccessController.doPrivileged(Native Method) 
~[na:1.8.0_65]
at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_65]
at 
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doWithSubjectAndActor(AbstractServlet.java:215)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at 
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:84)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) 
~[geronimo-servlet_3.0_spec-1.0.jar:1.0]
at 
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:465)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) 
~[geronimo-servlet_3.0_spec-1.0.jar:1.0]
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684) 
~[jetty-servlet-8.1.17.v20150415.jar:8.1.17.v20150415]
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
 [jetty-servlet-8.1.17.v20150415.jar:8.1.17.v20150415]
at 
org.apache.qpid.server.management.plugin.filter.ForbiddingAuthorisationFilter.doFilter(ForbiddingAuthorisationFilter.java:90)
 ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
at

[jira] [Commented] (QPID-6955) BufferOverflowException downloading message content

2015-12-16 Thread Rob Godfrey (JIRA) 

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

Rob Godfrey commented on QPID-6955:
---

So I think this is due to a bug I fixed this morning, which came to light after 
I committed my original change on QPID-6953.

The trivial fix in https://svn.apache.org/r1720340 should also apply to the 
6.0.0 code and I think would fix the issue (basically message.getSize() is 
returning 0 for all AMQP 1.0 messages, so an empty byte[] is being created to 
copy the message content into, causing the buffer overflow).

> BufferOverflowException downloading message content
> ---
>
> Key: QPID-6955
> URL: https://issues.apache.org/jira/browse/QPID-6955
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
> 2015-12-16 13:32:09,111 INFO  [Broker-Config] (q.m.b.startup) - [Broker] 
> BRK-1001 : Startup : Version: 6.0.0 Build: 1717754
> 2015-12-16 13:32:09,116 INFO  [Broker-Config] (q.m.b.platform) - [Broker] 
> BRK-1010 : Platform : JVM : Oracle Corporation version: 1.8.0_65-b17 OS : 
> Linux version: 2.6.32-573.8.1.el6.x86_64 arch: amd64 cores: 1
> 2015-12-16 13:32:09,118 INFO  [Broker-Config] (q.m.b.max_memory) - [Broker] 
> BRK-1011 : Maximum Memory : Heap : 528,154,624 bytes Direct : 1,610,612,736 
> bytes
>Reporter: Mark Soderquist
>
> Received the following exception when downloading message content from Qpid 
> HTTP Manager:
> 2015-12-16 13:29:31,768 ERROR [HttpManagement-HTTPS-117] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/queue/default/default/ext-zions-validation-mock/getMessageContent':
>  
> java.nio.BufferOverflowException: null
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:214) ~[na:1.8.0_65]
> at 
> org.apache.qpid.bytebuffer.QpidByteBuffer.copyTo(QpidByteBuffer.java:236) 
> ~[qpid-common-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.getContent(AbstractBDBMessageStore.java:1113)
>  ~[qpid-bdbstore-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:178)
>  ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.queue.AbstractQueue$MessageContentFinder.visit(AbstractQueue.java:3445)
>  ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.queue.AbstractQueue.visit(AbstractQueue.java:1799) 
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3349)
>  ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_65]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_65]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_65]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_65]
> at 
> org.apache.qpid.server.model.ConfiguredObjectOperation.perform(ConfiguredObjectOperation.java:155)
>  ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:634)
>  ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGetWithSubjectAndActor(RestServlet.java:358)
>  ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet$1.run(AbstractServlet.java:90)
>  ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet$1.run(AbstractServlet.java:86)
>  ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.8.0_65]
> at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_65]
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doWithSubjectAndActor(AbstractServlet.java:215)
>  ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:84)
>  ~[qpid-broker-plugins-management-http-6.0.0.jar:6.0.0]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) 
> ~[geronimo-servlet_3.0_spec-1.0.jar:1.0]
> at 
>

[jira] [Comment Edited] (QPID-6935) Infinite recursion resulting in huge number of Transfer objects created in Delivery, until OutOfMemory

2015-12-16 Thread Rob Godfrey (JIRA) 

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

Rob Godfrey edited comment on QPID-6935 at 12/16/15 8:18 PM:
-

So, from the screenshot it seems that each transfer object has a HeapByteBuffer 
which is backed by a different Java byte[].  Given this I don't think this is 
infinite recursion in the SessionEndpoint.sendTransfer - in send transfer the 
transfers will be backed by HeapByteBuffers which are backed by the same Java 
byte[] (as they are created by calling ByteBuffer.duplicate() ).  As such I 
believe we must be looking at a delivery created in 
SessionEndpoint.receiveTransfer()

So I think the client believes it is actually being sent many different 
transfer frames from the broker, all related to the same deliveryId.  We would 
have to look at protocol level debugging to see if the issue is the broker 
sending lots of frames with the same delivery id, or the client somehow 
processing the same frame over and over again.

Is the data inside each delivery the same, or do they have distinct content?

 


was (Author: rgodfrey):
So, from the screenshot it seems that each transfer object has a HeapByteBuffer 
which is backed by a different Java byte[].  Given this I don't think this is 
infinite recursion in the SessionEndpoint.sendTransfer - in send transfer the 
transfers will be backed by HeapByteBuffers which are backed by the same Java 
byte[] (as they are created by calling ByteBuffer.duplicate() ).

So I think the client believes it is actually being sent many different 
transfer frames from the broker, all related to the same deliveryId.  We would 
have to look at protocol level debugging to see if the issue is the broker 
sending lots of frames with the same delivery id, or the client somehow 
processing the same frame over and over again.

Is the data inside each delivery the same, or do they have distinct content?

 

> Infinite recursion resulting in huge number of Transfer objects created in 
> Delivery, until OutOfMemory
> --
>
> Key: QPID-6935
> URL: https://issues.apache.org/jira/browse/QPID-6935
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 1.0 Client
>Affects Versions: 0.32
> Environment: Linux RedHat 7
>Reporter: Leo Riguspi
>Priority: Blocker
> Attachments: Heap.png, Heap2.png, memory_dump.txt, snapshot1.png, 
> snapshot2.png
>
>
> We have an Apache ActiveMQ 5.12 running for 2 months now and a Java AMQP 
> client publishing a few messages every few minutes. Messages are small, less 
> than 1K and are immediately consumed.
> For the second time in two months the client exploded with an OutOfMemory 
> error. By analysing the memory the culprit seems to be the ArrayList of 
> Trasfer objects in the Delivery. All of a sudden, for some reason it just 
> keeps creating new Trasfers until the memory is full.
> We have a screenshot of the memory dump in which there are more than 49000 
> Trasfer objects in the same Delivery. Unfortunately there seems to be no way 
> to attach it to this issue.
> We did not find a way to reproduce the problem but it looks like some 
> combination of conditions cause the SessionEndpoint::sendTransfer recursive 
> method to call itself over and over, each time adding a new Transfer object. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-142) Clean up the IdGenerator used to create ID values for JMS resources

2015-12-16 Thread ASF subversion and git services (JIRA) 

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

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

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

QPIDJMS-142 Remove much of the legacy generation code and use a simple
UUID plus sequence value, reduces complexity and removes some locking +
startup delay.

> Clean up the IdGenerator used to create ID values for JMS resources
> ---
>
> Key: QPIDJMS-142
> URL: https://issues.apache.org/jira/browse/QPIDJMS-142
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.7.0
>
>
> The current IdGenerator implementation uses some less than optimal logic to 
> create ID values for the JMS resources.  We can streamline and simplify this 
> using UUID values with some optional additional identifying bits.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6935) Infinite recursion resulting in huge number of Transfer objects created in Delivery, until OutOfMemory

2015-12-16 Thread Leo Riguspi (JIRA) 

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

Leo Riguspi updated QPID-6935:
--
Attachment: Heap.png
Heap2.png

Hi, it just happened for the third time. 
By looking more closely at the heap dump we have identified the queues where 
this happens. It looks like the problem occurs when using Apache Camel to 
automatically forward messages from one queue to other queues. I have attached 
two additional screenshots, don't know if they can help.

> Infinite recursion resulting in huge number of Transfer objects created in 
> Delivery, until OutOfMemory
> --
>
> Key: QPID-6935
> URL: https://issues.apache.org/jira/browse/QPID-6935
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 1.0 Client
>Affects Versions: 0.32
> Environment: Linux RedHat 7
>Reporter: Leo Riguspi
>Priority: Blocker
> Attachments: Heap.png, Heap2.png, memory_dump.txt, snapshot1.png, 
> snapshot2.png
>
>
> We have an Apache ActiveMQ 5.12 running for 2 months now and a Java AMQP 
> client publishing a few messages every few minutes. Messages are small, less 
> than 1K and are immediately consumed.
> For the second time in two months the client exploded with an OutOfMemory 
> error. By analysing the memory the culprit seems to be the ArrayList of 
> Trasfer objects in the Delivery. All of a sudden, for some reason it just 
> keeps creating new Trasfers until the memory is full.
> We have a screenshot of the memory dump in which there are more than 49000 
> Trasfer objects in the same Delivery. Unfortunately there seems to be no way 
> to attach it to this issue.
> We did not find a way to reproduce the problem but it looks like some 
> combination of conditions cause the SessionEndpoint::sendTransfer recursive 
> method to call itself over and over, each time adding a new Transfer object. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Review Request 41456: Add message annotation support to the C++ bindings

2015-12-16 Thread Kim van der Riet 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41456/
---

Review request for qpid and Alan Conway.


Repository: qpid-proton-git


Description
---

Qpid-interop-test needs to use annotations in the c++ bindings for JMS messages 
which rely upon them for successfully identifying a message type.  This patch 
is the bare-bones only, there are no comments or tests.


Diffs
-

  proton-c/bindings/cpp/include/proton/message.hpp 0954b49 
  proton-c/bindings/cpp/src/message.cpp dd57606 

Diff: https://reviews.apache.org/r/41456/diff/


Testing
---

Tested within qpid-interop-test for JMS message tests, works as expected.


Thanks,

Kim van der Riet

[jira] [Commented] (QPID-6944) High CPU use sending message

2015-12-16 Thread Mark Soderquist (JIRA) 

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

Mark Soderquist commented on QPID-6944:
---

I changed the Oracle BDB JE library to 5.0.104 but I ended up with the same 
behavior. That pretty much rules out BDB I think.

> High CPU use sending message
> 
>
> Key: QPID-6944
> URL: https://issues.apache.org/jira/browse/QPID-6944
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
>Reporter: Mark Soderquist
> Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, 
> qpid.cpu.png, qpid.cpu.png, qpid.log.zip, qpid6944.zip, 
> threaddump-1449856663270.tdump
>
>
> The org.apache.qpid.server.transport.SelectorThread is causing live lock. 
> While the application still functions it causes the CPU to run at nearly 
> 100%. See attached thread dump.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-6944) High CPU use sending message

2015-12-16 Thread Mark Soderquist (JIRA) 

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

Mark Soderquist updated QPID-6944:
--
Attachment: virtualhosts.xml
config.json
broker.acl

I've uploaded some configuration files for review (with passwords removed), 
just in case you see something odd.

> High CPU use sending message
> 
>
> Key: QPID-6944
> URL: https://issues.apache.org/jira/browse/QPID-6944
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
>Reporter: Mark Soderquist
> Attachments: broker.acl, config.json, enabledebug.png, qpid.0.32.png, 
> qpid.6.0.png, qpid.cpu.png, qpid.cpu.png, qpid.log.zip, qpid6944.zip, 
> threaddump-1449856663270.tdump, virtualhosts.xml
>
>
> The org.apache.qpid.server.transport.SelectorThread is causing live lock. 
> While the application still functions it causes the CPU to run at nearly 
> 100%. See attached thread dump.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-179) Refactor Router Core

2015-12-16 Thread ASF subversion and git services (JIRA) 

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

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

Commit fc2c243e9c02104e5b6ae6f01ab715ad850b449a in qpid-dispatch's branch 
refs/heads/tross-DISPATCH-179-1 from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=fc2c243 ]

DISPATCH-179 - Final changes to core before ripping out the deprecated 
connection
   and link logic.


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-179) Refactor Router Core

2015-12-16 Thread ASF subversion and git services (JIRA) 

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

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

Commit ca24d67f0a8394836417e988630bb9810420b965 in qpid-dispatch's branch 
refs/heads/tross-DISPATCH-179-1 from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ca24d67 ]

DISPATCH-179 - WIP checkpoint.
   Ripped out large sections of the old architecture.
   Added the general callback functionality for 
non-connection-specific actions.


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-122) Profile performance and investigate improvements

2015-12-16 Thread ASF subversion and git services (JIRA) 

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

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

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

QPIDJMS-122 Minor tweak to avoid a couple unneeded array reallocations +
content copies.  

> Profile performance and investigate improvements 
> -
>
> Key: QPIDJMS-122
> URL: https://issues.apache.org/jira/browse/QPIDJMS-122
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.7.0
>
>
> Using some common messaging patterns profile client performance and improve 
> when possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request: NO-JIRA: Added dockerfiles that will h...

2015-12-16 Thread ganeshmurthy 
Github user ganeshmurthy closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-dispatch pull request: DISPATCH-199 - Added dockerfiles that ...

2015-12-16 Thread ganeshmurthy 
GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-199 - Added dockerfiles that will help launch the dispatch r…

…outer inside docker containers

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-199-1

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

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


commit a6d5be7b57c9943cd42a00ad7eedb0ff638c8354
Author: ganeshmurthy 
Date:   2015-12-14T16:13:56Z

DISPATCH-199 - Added dockerfiles that will help launch the dispatch router 
inside docker containers




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Created] (DISPATCH-200) Flexible mapping from x.509 certificates to an identity

2015-12-16 Thread Ted Ross (JIRA) 
Ted Ross created DISPATCH-200:
-

 Summary: Flexible mapping from x.509 certificates to an identity
 Key: DISPATCH-200
 URL: https://issues.apache.org/jira/browse/DISPATCH-200
 Project: Qpid Dispatch
  Issue Type: New Feature
  Components: Container
Reporter: Ted Ross
Assignee: Ganesh Murthy
 Fix For: 0.7


x.509 certificates contain structured data.  It is necessary to be able to 
generate a unique identity from a certificate for the purpose of indexing into 
access policy.
The proposed feature will contain a descriptor that is part of an ssl-profile 
configuration that specifies the format and content of the identity in terms of 
the fields of a certificate.
For example, the identity can be the certificate fingerprint, or the 
distinguished name, or the combination of more than one field.

A further enhancement is to provide a secondary mapping from the above identity 
to a configured nickname.  For example, a user may want to use the fingerprint 
as the identity field but wishes to write policy and view management data 
containing a more friendly "display" name rather than the raw fingerprint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-199) Add Dockerfiles that launches the dispatch router inside a container for RHEL and Debian based systems

2015-12-16 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on DISPATCH-199:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-199 - Added dockerfiles that will help launch the dispatch r…

…outer inside docker containers

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-199-1

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

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


commit a6d5be7b57c9943cd42a00ad7eedb0ff638c8354
Author: ganeshmurthy 
Date:   2015-12-14T16:13:56Z

DISPATCH-199 - Added dockerfiles that will help launch the dispatch router 
inside docker containers




> Add Dockerfiles that launches the dispatch router inside a container for RHEL 
> and Debian based systems
> --
>
> Key: DISPATCH-199
> URL: https://issues.apache.org/jira/browse/DISPATCH-199
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Ganesh Murthy
>
> Add sample dockerfiles that launch dispatch router inside a docker container.
> Create dockerfiles for RHEL and Debian based systems.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6954) [Java Broker] Add the ability to define "policies" for node auto-creation based on address

2015-12-16 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1720368 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1720368 ]

QPID-6954 : Ensure durable queues are actually stored

> [Java Broker] Add the ability to define "policies" for node auto-creation 
> based on address
> --
>
> Key: QPID-6954
> URL: https://issues.apache.org/jira/browse/QPID-6954
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> See: [this 
> mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
>  and QPID-5251 (C++ Broker equivalent).
> It is sometimes useful to be able to provide behaviours based on 
> namespaces/patterns such that queues/exchanges which match those patterns get 
> automatically created.
> Add a new property to the virtualHost called "nodeAutoCreationPolicies", 
> which is a list of polices.  A policy is an object with attributes "pattern", 
> "nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
> * pattern is a Java RegExp which will be matched against the name used by the 
> client for an incoming published message / consume request.
> * nodeType is one of "queue" or "exchange".
> * createdOnPublish is a boolean indicating whether the node should be created 
> when new messages are published (or an incoming link is created)
> * createdOnConsume is a boolean indicating whether the node should be created 
> when a new consumer is created
> * attributes is a map, containing the default attributes of the node to be 
> created.  These attributes are the same used in the REST API for the node 
> type.
> The nodeAutoCreationPolicies can be set via the REST API, or (if you are 
> using a JSON VirtualHostNode) by hand editing the virtualHost configuration.
> For instance here is a snippet from a JSON virtualHost configuration with 
> defined nodeAutoCreationPolicies:
> {code:javascript}
> {
>   "id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
>   "name" : "default",
>   "type" : "BDB",
>   "modelVersion" : "6.1",
>   "nodeAutoCreationPolicies" : [ {
> "pattern" : "rob\\.durable\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : true,
> "nodeType" : "queue",
> "attributes" : {
>   "durable" : true
> }
>   }, {
> "pattern" : "rob\\.exchange\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : false,
> "nodeType" : "exchange",
> "attributes" : {
>   "type" : "direct",
>   "durable" : true
> }
>   } ],
>   "queue.deadLetterQueueEnabled" : false,
>   "exchanges" : [ {
> "id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
> "name" : "amq.direct",
> "type" : "direct"
>   }, {
> "id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
> "name" : "amq.fanout",
> "type" : "fanout"
>   }, {
> "id" : "45e9eba0-3bcc-4634-b042-87a652447cbe",
> "name" : "amq.match",
> "type" : "headers"
>   }, {
> "id" : "d7b703c4-0d64-4a44-8008-1314a18e30e7",
> "name" : "amq.topic",
> "type" : "topic"
>   } ],
> {code}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output

2015-12-16 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1720340 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1720340 ]

QPID-6953 : Fix getContentSize() in AMQP 1.0 implementation

> [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use 
> QpidByteBuffer for encoding output
> -
>
> Key: QPID-6953
> URL: https://issues.apache.org/jira/browse/QPID-6953
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for 
> encoding, one which uses a "DataOutput" object, and one which uses a 
> QpidByteBuffer or ByteBufferSender.  Examples of the former should be 
> removed, and the latter used exclusively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (QPID-6944) High CPU use sending message

2015-12-16 Thread Keith Wall (JIRA) 

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

Keith Wall edited comment on QPID-6944 at 12/16/15 1:25 PM:


Hi Mark,

I have tried running {{Qpid6944}} (on separate host) with a 6.0.0 Broker that 
uses AMQPS (TLS) and BDB based virtual host on a platform that uses RHEL 6.6 
Santiago.  I am not seeing the same CPU behaviour as you (observing CPU using 
jvisualvm attached to the Qpid Broker's JVM)

I wasn't too clear on how you were using your reproduction, so I've tried two 
things:

# I put a loop in {{Qpid6944#run()}} (so it creates a connection, sends 
message, closes connection) and left the program  running for some time.  CPU 
utilisation is flat at 6.1%.
# I put a loop in {{Qpid6944#send()}} (so it creates a connection, sent 
messages (1000) , sleep(50ms), repeat last two steps 50 times,  close 
connection)  CPU utilising was even lower (hardly perceivable on the jvisualvm 
chart)

I did not run {{AmqpMessageReader}}.

I have tested this with Oracle JDK 1.8 0_60 and Oracle JDK 1.7.0_67.   

One difference I cannot eliminate is the Oracle BDB JE.  I cannot test with JE 
versions higher than 5.0.104 owing to the licence change. 

Can you confirm that I am conducting the test as you do?  Also, can you retest 
with Oracle BDB JE 5.0.104.  I'd be surprised if this were the issue, but it'll 
eliminate from the enquiry all the same.

I need to review the qpid.log you have sent more carefully.  I hope to have 
some more time later today.  I hope to have some more ideas.








 


was (Author: k-wall):
Hi Mark,

I have tried running {{Qpid6944}} (on separate host) with a 6.0.0 Broker that 
uses AMQPS (TLS) and BDB based virtual host on a platform that uses RHEL 6.6 
Santiago.  I am not seeing the same CPU behaviour as you (observing CPU using 
jvisualvm attached to the Qpid Broker's JVM)

I wasn't too clear on how you were using your reproduction, so I've tried two 
things:

# I put a loop in {{Qpid6944#run()}} (so it creates a connection, sends 
message, closes connection) and left the program  running for some time.  CPU 
utilisation is flat at 6.1%.
# I put a loop in Qpid6944#send() (so it creates a connection, sent messages 
(1000) , sleep(50ms), repeat last two steps 50 times,  close connection)  CPU 
utilising was even lower (hardly perceivable on the jvisualvm chart)

I did not run {{AmqpMessageReader}}.

I have tested this with Oracle JDK 1.8 0_60 and Oracle JDK 1.7.0_67.   

One difference I cannot eliminate is the Oracle BDB JE.  I cannot test with JE 
versions higher than 5.0.104 owing to the licence change. 

Can you confirm that I am conducting the test as you do?  Also, can you retest 
with Oracle BDB JE 5.0.104.  I'd be surprised if this were the issue, but it'll 
eliminate from the enquiry all the same.

I need to review the qpid.log you have sent more carefully.  I hope to have 
some more time later today.  I hope to have some more ideas.








 

> High CPU use sending message
> 
>
> Key: QPID-6944
> URL: https://issues.apache.org/jira/browse/QPID-6944
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
>Reporter: Mark Soderquist
> Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, 
> qpid.cpu.png, qpid.cpu.png, qpid.log.zip, qpid6944.zip, 
> threaddump-1449856663270.tdump
>
>
> The org.apache.qpid.server.transport.SelectorThread is causing live lock. 
> While the application still functions it causes the CPU to run at nearly 
> 100%. See attached thread dump.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output

2015-12-16 Thread Keith Wall (JIRA) 

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

Keith Wall commented on QPID-6953:
--

This commit has broken AMQP 1.0 support in the Broker (for both AMQP 1.0 
clients).  See the Jenkins Joram jobs.

https://builds.apache.org/job/Qpid-Java-JoramJMSTest/208/jdk=latest1.7,label=Ubuntu,qpid.joramtests=qpid-jms-client/testReport/junit/org.objectweb.jtests.jms.conform.message.headers/MessageHeaderTest/testJMSMessageID_2/

First failure looks like this.

{noformat}
Tests run: 9, Failures: 2, Errors: 1, Skipped: 0, Time elapsed: 0.986 sec <<< 
FAILURE! - in org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest
testJMSMessageID_2(org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest)
  Time elapsed: 0.113 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest.testJMSMessageID_2(MessageHeaderTest.java:128)
{noformat}





> [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use 
> QpidByteBuffer for encoding output
> -
>
> Key: QPID-6953
> URL: https://issues.apache.org/jira/browse/QPID-6953
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for 
> encoding, one which uses a "DataOutput" object, and one which uses a 
> QpidByteBuffer or ByteBufferSender.  Examples of the former should be 
> removed, and the latter used exclusively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (QPID-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output

2015-12-16 Thread Keith Wall (JIRA) 

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

Keith Wall edited comment on QPID-6953 at 12/16/15 10:31 AM:
-

This commit has broken AMQP 1.0 support in the Broker (for both AMQP 1.0 
clients).  See the Jenkins Joram jobs.  Problem is reproducible for me on my 
laptop too.

https://builds.apache.org/job/Qpid-Java-JoramJMSTest/208/jdk=latest1.7,label=Ubuntu,qpid.joramtests=qpid-jms-client/testReport/junit/org.objectweb.jtests.jms.conform.message.headers/MessageHeaderTest/testJMSMessageID_2/

First failure looks like this.

{noformat}
Tests run: 9, Failures: 2, Errors: 1, Skipped: 0, Time elapsed: 0.986 sec <<< 
FAILURE! - in org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest
testJMSMessageID_2(org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest)
  Time elapsed: 0.113 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest.testJMSMessageID_2(MessageHeaderTest.java:128)
{noformat}






was (Author: k-wall):
This commit has broken AMQP 1.0 support in the Broker (for both AMQP 1.0 
clients).  See the Jenkins Joram jobs.

https://builds.apache.org/job/Qpid-Java-JoramJMSTest/208/jdk=latest1.7,label=Ubuntu,qpid.joramtests=qpid-jms-client/testReport/junit/org.objectweb.jtests.jms.conform.message.headers/MessageHeaderTest/testJMSMessageID_2/

First failure looks like this.

{noformat}
Tests run: 9, Failures: 2, Errors: 1, Skipped: 0, Time elapsed: 0.986 sec <<< 
FAILURE! - in org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest
testJMSMessageID_2(org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest)
  Time elapsed: 0.113 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.objectweb.jtests.jms.conform.message.headers.MessageHeaderTest.testJMSMessageID_2(MessageHeaderTest.java:128)
{noformat}





> [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use 
> QpidByteBuffer for encoding output
> -
>
> Key: QPID-6953
> URL: https://issues.apache.org/jira/browse/QPID-6953
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for 
> encoding, one which uses a "DataOutput" object, and one which uses a 
> QpidByteBuffer or ByteBufferSender.  Examples of the former should be 
> removed, and the latter used exclusively.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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