[jira] [Commented] (PROTON-1488) Making Python server example more configurable

2017-05-22 Thread Gordon Sim (JIRA) 

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

Gordon Sim commented on PROTON-1488:


This is a good improvement. Just for the sake of consistency with client.py and 
all the other examples that have command line options, I wonder if we should 
stick with the --address option being a full url? We can then pull the 
host:port and path out of it. Wdyt?

> Making Python server example more configurable
> --
>
> Key: PROTON-1488
> URL: https://issues.apache.org/jira/browse/PROTON-1488
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: examples
>Reporter: Paolo Patierno
>Priority: Trivial
>
> Hi,
> it should be good having the Python server.py example more configurable from 
> the command line in order to specify the URL and the address.
> Thanks,
> Paolo. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7723) [0-10] Re-encoding of the 0-10 message during computation of updateStatsOnEnqueue causes performance slow down

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 400e7ec7090fd2135996a43343e885889adfd78d 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=400e7ec ]

QPID-7723: [0-10] Allow header to be optional when computing the encoded size


> [0-10] Re-encoding of the 0-10 message during computation of 
> updateStatsOnEnqueue causes performance slow down
> --
>
> Key: QPID-7723
> URL: https://issues.apache.org/jira/browse/QPID-7723
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
> Attachments: hotspot_comparison.tar.bz2
>
>
> We are seeing a slowdown in the Java Broker for the 0-10 protocol since 
> February 2017.  Investigation with JProfiler is pointing to the introduction 
> of the ring queue feature as being a possible cause.   The performance drop 
> is most apparent with on the transient profiles, where the drop is around 
> ~2-3%.
> The problem is the new call to MessageMetaData_0_10#getStorableSize made from 
> AbstractQueueEntryList#updateStatsOnEnqueue. On the 0-10 path, this causes 
> the header delivery properties/message properties/non standard delivery 
> properties to be encoded in order to compute the store size.  This encoding 
> step is separate to the encoding step that takes place when the message is 
> sent to a consumer.  The up shot is that the headers for a transient message 
> that is not flown to disk are now encoded twice rather than once.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7723) [0-10] Re-encoding of the 0-10 message during computation of updateStatsOnEnqueue causes performance slow down

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-7723: Optimize evaluation of metadata storable size for AMQP 0-10


> [0-10] Re-encoding of the 0-10 message during computation of 
> updateStatsOnEnqueue causes performance slow down
> --
>
> Key: QPID-7723
> URL: https://issues.apache.org/jira/browse/QPID-7723
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
> Attachments: hotspot_comparison.tar.bz2
>
>
> We are seeing a slowdown in the Java Broker for the 0-10 protocol since 
> February 2017.  Investigation with JProfiler is pointing to the introduction 
> of the ring queue feature as being a possible cause.   The performance drop 
> is most apparent with on the transient profiles, where the drop is around 
> ~2-3%.
> The problem is the new call to MessageMetaData_0_10#getStorableSize made from 
> AbstractQueueEntryList#updateStatsOnEnqueue. On the 0-10 path, this causes 
> the header delivery properties/message properties/non standard delivery 
> properties to be encoded in order to compute the store size.  This encoding 
> step is separate to the encoding step that takes place when the message is 
> sent to a consumer.  The up shot is that the headers for a transient message 
> that is not flown to disk are now encoded twice rather than once.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7783) Closing a virtualhost does not dispose QBBs associated with messages on queues

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 6d6f80145810d8aa81bedde129a910e198b74ca2 in qpid-broker-j's branch 
refs/heads/6.1.x from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6d6f801 ]

QPID-7783: [Java Broker] Dispose of QpidByteBuffers associated with message 
content/headers when stopping/closing a VirtualHost

Cherry-picked from b63815c


> Closing a virtualhost does not dispose QBBs associated with messages on queues
> --
>
> Key: QPID-7783
> URL: https://issues.apache.org/jira/browse/QPID-7783
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.6, qpid-java-6.1, 
> qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> If I close a virtualhost (either via management or owing to a change of HA 
> mastership), the QBBs that hold message header and payload don't get 
> released.  The QBBs won't fall back into the  pool and the JVMs will have to 
> reclaim the direct memory (which it does inefficiently).
> On trunk, this causes the value returned by 
> {{QBB.getNumberOfActivePooledBuffers()}} to be incorrect.   This value is 
> used to determine when to flow to disk, to this would cause flow to disk to 
> be more frequent than it needs.
> This problem does exist on 6.0/6.1, but is not particular impactful.   The 
> garbage collector will eventually collect the QBBs associated with the 
> messages.  As the recovery paths uses heap byte buffers: messages recovered 
> by it are not affected by this problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7775) Flow to disk should consider the size of the resident messages in memory.

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit b19219217d410f3d45bc356e8e1113d6a16229ea 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=b192192 ]

QPID-7795: [Java Broker] Ensure that a newly enqueued message that is flowed to 
disk does not immediately have meta-data reloaded (6.1/6.0)

Cherry picked from QPID-7775 commit 8ae1d142b33edc91d4988c9f4b775026bb03acc4


> Flow to disk should consider the size of the resident messages in memory.
> -
>
> Key: QPID-7775
> URL: https://issues.apache.org/jira/browse/QPID-7775
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Our current algorithm for triggering flow to disk has some shortcomings.
> * the algorithm does not account for memory returned by flow to disk.
> The decision to flow a message a newly arriving message to disk
> considers only the queue's target size and queue's depth.  Once a
> queue depth is over its target, all messages will go to disk even if
> all messages have actually been flowed to disk.  The same is true
> after recovery: flow to disk will be enabled even though there are no
> messages in RAM.
> * the fact that a queue's target size is assigned by periodically by
> housekeeping means that the queues target size can be wrong for most
> of the time.  This is very apparent if a queue is growing; you
> actually see *most* messages flowing to disk even when there is ample
> memory.  The target size is periodically recomputed but only remains
> correct for an instant, the queue returns to the flow to disk state as
> more messages are added.   We see this during perf test runs.
> We will change the MessageStore so that it tracks the size of the messages 
> that are held resident in memory.The flow to disk algorithm will be 
> change to by triggered when the resident memory exceeds the virtual host's 
> target size.
> This work is likely to fully replace the recent work done on QPID-7770.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7794) [Java Broker] Periodically report the number of bytes evacuated from memory by flow to disk (6.1/6.0)

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 5920ed77709c66b6a110fac04e9368a125f6ff2b in qpid-broker-j's branch 
refs/heads/6.1.x from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=5920ed7 ]

QPID-7794: [Java Broker] Periodically report the number of bytes evacuated from 
memory by flow to disk

These are the Store parts required.


> [Java Broker] Periodically report the number of bytes evacuated from memory 
> by flow to disk (6.1/6.0)
> -
>
> Key: QPID-7794
> URL: https://issues.apache.org/jira/browse/QPID-7794
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.7, qpid-java-6.1.3
>
>
> On master this was fixed as part of QPID-7775.
> We only want to backport the log part.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7794) [Java Broker] Periodically report the number of bytes evacuated from memory by flow to disk (6.1/6.0)

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-7794: [Java Broker] periodically log flow to disk statistics on VirtualHost


> [Java Broker] Periodically report the number of bytes evacuated from memory 
> by flow to disk (6.1/6.0)
> -
>
> Key: QPID-7794
> URL: https://issues.apache.org/jira/browse/QPID-7794
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.7, qpid-java-6.1.3
>
>
> On master this was fixed as part of QPID-7775.
> We only want to backport the log part.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7795) [Java Broker] Ensure that a newly enqueued message that is flowed to disk does not immediately have meta-data reloaded (6.1/6.0)

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit b19219217d410f3d45bc356e8e1113d6a16229ea 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=b192192 ]

QPID-7795: [Java Broker] Ensure that a newly enqueued message that is flowed to 
disk does not immediately have meta-data reloaded (6.1/6.0)

Cherry picked from QPID-7775 commit 8ae1d142b33edc91d4988c9f4b775026bb03acc4


> [Java Broker] Ensure that a newly enqueued message that is flowed to disk 
> does not immediately have meta-data reloaded (6.1/6.0)
> 
>
> Key: QPID-7795
> URL: https://issues.apache.org/jira/browse/QPID-7795
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.7, qpid-java-6.1.3
>
>
> Ensure that a newly enqueued message that is flowed to disk does not 
> immediately have meta-data reloaded.
> This is fixed on master by QPID-7775.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7784) Closing a virtualhost does not dispose QBBs still associated with pooled IO threads

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-7784: [Java Broker] Dispose QpidByteBuffers associated with pooled threads 
when shutting down executors.

Cherry picked from d9af2660089139e2f4fdad8c0aa0e0c8e6529ff5


> Closing a virtualhost does not dispose QBBs still associated with pooled IO 
> threads
> ---
>
> Key: QPID-7784
> URL: https://issues.apache.org/jira/browse/QPID-7784
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.6, qpid-java-6.1, 
> qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> If I close a virtualhost (either via management or owing to a change of HA 
> mastership), the QBBs that are associated with pooled IO threads don't get 
> disposed.
> This causes the value returned by {{QBB.getNumberOfActivePooledBuffers()}} to 
> be incorrect.  This value is used to determine when to flow to disk, to this 
> would cause flow to disk to be more frequent than it needs.
> This problem does exist on 6.0/6.1, but is not particular impactful.   The 
> garbage collector will eventually collect the QBBs and the associated direct 
> memory.   The number of threads in the pool is small, so this probably won't 
> cause a problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (PROTON-1489) Disable error messages

2017-05-22 Thread Al Costa (JIRA) 
Al Costa created PROTON-1489:


 Summary: Disable error messages
 Key: PROTON-1489
 URL: https://issues.apache.org/jira/browse/PROTON-1489
 Project: Qpid Proton
  Issue Type: Improvement
Reporter: Al Costa


It would be great if there could be a way to simply disable connection error 
messages. I am using proton for an especific function I KNOW will generate 
errors and that's perfectly fine, but seeing a bunch of "
ERROR:root:proton:io: recv: Connection refused" before each connection is just 
irritating.

Hope that was useful




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7723) [0-10] Re-encoding of the 0-10 message during computation of updateStatsOnEnqueue causes performance slow down

2017-05-22 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack updated QPID-7723:
---
Fix Version/s: qpid-java-6.1.3
   qpid-java-6.0.7

> [0-10] Re-encoding of the 0-10 message during computation of 
> updateStatsOnEnqueue causes performance slow down
> --
>
> Key: QPID-7723
> URL: https://issues.apache.org/jira/browse/QPID-7723
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
> Attachments: hotspot_comparison.tar.bz2
>
>
> We are seeing a slowdown in the Java Broker for the 0-10 protocol since 
> February 2017.  Investigation with JProfiler is pointing to the introduction 
> of the ring queue feature as being a possible cause.   The performance drop 
> is most apparent with on the transient profiles, where the drop is around 
> ~2-3%.
> The problem is the new call to MessageMetaData_0_10#getStorableSize made from 
> AbstractQueueEntryList#updateStatsOnEnqueue. On the 0-10 path, this causes 
> the header delivery properties/message properties/non standard delivery 
> properties to be encoded in order to compute the store size.  This encoding 
> step is separate to the encoding step that takes place when the message is 
> sent to a consumer.  The up shot is that the headers for a transient message 
> that is not flown to disk are now encoded twice rather than once.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (PROTON-1488) Making Python server example more configurable

2017-05-22 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on PROTON-1488:


GitHub user ppatierno opened a pull request:

https://github.com/apache/qpid-proton/pull/106

Added command line parameters for configure URL and address

It refers to this https://issues.apache.org/jira/browse/PROTON-1488

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

$ git pull https://github.com/ppatierno/qpid-proton master

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

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


commit 1f8c94004214a2f159da592c71a61bef39aa52f8
Author: ppatierno 
Date:   2017-05-22T15:26:16Z

Added command line parameters for configure URL and address




> Making Python server example more configurable
> --
>
> Key: PROTON-1488
> URL: https://issues.apache.org/jira/browse/PROTON-1488
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: examples
>Reporter: Paolo Patierno
>Priority: Trivial
>
> Hi,
> it should be good having the Python server.py example more configurable from 
> the command line in order to specify the URL and the address.
> Thanks,
> Paolo. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] qpid-proton pull request #106: Added command line parameters for configure U...

2017-05-22 Thread ppatierno 
GitHub user ppatierno opened a pull request:

https://github.com/apache/qpid-proton/pull/106

Added command line parameters for configure URL and address

It refers to this https://issues.apache.org/jira/browse/PROTON-1488

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

$ git pull https://github.com/ppatierno/qpid-proton master

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

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


commit 1f8c94004214a2f159da592c71a61bef39aa52f8
Author: ppatierno 
Date:   2017-05-22T15:26:16Z

Added command line parameters for configure URL and address




---
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] (PROTON-1488) Making Python server example more configurable

2017-05-22 Thread Paolo Patierno (JIRA) 
Paolo Patierno created PROTON-1488:
--

 Summary: Making Python server example more configurable
 Key: PROTON-1488
 URL: https://issues.apache.org/jira/browse/PROTON-1488
 Project: Qpid Proton
  Issue Type: Improvement
  Components: examples
Reporter: Paolo Patierno
Priority: Trivial


Hi,
it should be good having the Python server.py example more configurable from 
the command line in order to specify the URL and the address.

Thanks,
Paolo. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPID-7795) [Java Broker] Ensure that a newly enqueued message that is flowed to disk does not immediately have meta-data reloaded (6.1/6.0)

2017-05-22 Thread Lorenz Quack (JIRA) 
Lorenz Quack created QPID-7795:
--

 Summary: [Java Broker] Ensure that a newly enqueued message that 
is flowed to disk does not immediately have meta-data reloaded (6.1/6.0)
 Key: QPID-7795
 URL: https://issues.apache.org/jira/browse/QPID-7795
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.1, qpid-java-6.0
Reporter: Lorenz Quack
 Fix For: qpid-java-6.0.7, qpid-java-6.1.3


Ensure that a newly enqueued message that is flowed to disk does not 
immediately have meta-data reloaded.

This is fixed on master by QPID-7775.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPID-7794) [Java Broker] Periodically report the number of bytes evacuated from memory by flow to disk (6.1/6.0)

2017-05-22 Thread Lorenz Quack (JIRA) 
Lorenz Quack created QPID-7794:
--

 Summary: [Java Broker] Periodically report the number of bytes 
evacuated from memory by flow to disk (6.1/6.0)
 Key: QPID-7794
 URL: https://issues.apache.org/jira/browse/QPID-7794
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Lorenz Quack
 Fix For: qpid-java-6.0.7, qpid-java-6.1.3


On master this was fixed as part of QPID-7775.
We only want to backport the log part.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7784) Closing a virtualhost does not dispose QBBs still associated with pooled IO threads

2017-05-22 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack updated QPID-7784:
---
Fix Version/s: qpid-java-6.1.3
   qpid-java-6.0.7

> Closing a virtualhost does not dispose QBBs still associated with pooled IO 
> threads
> ---
>
> Key: QPID-7784
> URL: https://issues.apache.org/jira/browse/QPID-7784
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.6, qpid-java-6.1, 
> qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> If I close a virtualhost (either via management or owing to a change of HA 
> mastership), the QBBs that are associated with pooled IO threads don't get 
> disposed.
> This causes the value returned by {{QBB.getNumberOfActivePooledBuffers()}} to 
> be incorrect.  This value is used to determine when to flow to disk, to this 
> would cause flow to disk to be more frequent than it needs.
> This problem does exist on 6.0/6.1, but is not particular impactful.   The 
> garbage collector will eventually collect the QBBs and the associated direct 
> memory.   The number of threads in the pool is small, so this probably won't 
> cause a problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7763) [Java Broker] Flow to disk if allocated direct memory exceeds broker wide broker.flowToDiskThreshold

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 516854eae4bcd1fa833db107f8590e52b23e66e6 in qpid-broker-j's branch 
refs/heads/6.0.x from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=516854e ]

QPID-7763: Correct return type of getAllocatedDirectMemorySize from int to long

(cherry picked from commit 00a19f1953fee7c562edf11a9bb6118c253e198e)


> [Java Broker] Flow to disk if allocated direct memory exceeds broker wide 
> broker.flowToDiskThreshold
> 
>
> Key: QPID-7763
> URL: https://issues.apache.org/jira/browse/QPID-7763
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> Currently the broker.flowToDiskThreshold is compared against the size used by 
> messages on queues.
> However, the intent was to have a mechanism for preventing the broker going 
> out of direct memory. For this it is much more interesting to observe how 
> much direct memory the QpidByteBuffers use. The two numbers can easily differ 
> since the QBB can be sparsely populated. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7783) Closing a virtualhost does not dispose QBBs associated with messages on queues

2017-05-22 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack updated QPID-7783:
---
Fix Version/s: qpid-java-6.1.3
   qpid-java-6.0.7

> Closing a virtualhost does not dispose QBBs associated with messages on queues
> --
>
> Key: QPID-7783
> URL: https://issues.apache.org/jira/browse/QPID-7783
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.6, qpid-java-6.1, 
> qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> If I close a virtualhost (either via management or owing to a change of HA 
> mastership), the QBBs that hold message header and payload don't get 
> released.  The QBBs won't fall back into the  pool and the JVMs will have to 
> reclaim the direct memory (which it does inefficiently).
> On trunk, this causes the value returned by 
> {{QBB.getNumberOfActivePooledBuffers()}} to be incorrect.   This value is 
> used to determine when to flow to disk, to this would cause flow to disk to 
> be more frequent than it needs.
> This problem does exist on 6.0/6.1, but is not particular impactful.   The 
> garbage collector will eventually collect the QBBs associated with the 
> messages.  As the recovery paths uses heap byte buffers: messages recovered 
> by it are not affected by this problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7763) [Java Broker] Flow to disk if allocated direct memory exceeds broker wide broker.flowToDiskThreshold

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 00a19f1953fee7c562edf11a9bb6118c253e198e in qpid-broker-j's branch 
refs/heads/6.1.x from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=00a19f1 ]

QPID-7763: Correct return type of getAllocatedDirectMemorySize from int to long


> [Java Broker] Flow to disk if allocated direct memory exceeds broker wide 
> broker.flowToDiskThreshold
> 
>
> Key: QPID-7763
> URL: https://issues.apache.org/jira/browse/QPID-7763
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> Currently the broker.flowToDiskThreshold is compared against the size used by 
> messages on queues.
> However, the intent was to have a mechanism for preventing the broker going 
> out of direct memory. For this it is much more interesting to observe how 
> much direct memory the QpidByteBuffers use. The two numbers can easily differ 
> since the QBB can be sparsely populated. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7763) [Java Broker] Flow to disk if allocated direct memory exceeds broker wide broker.flowToDiskThreshold

2017-05-22 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack commented on QPID-7763:


There is an additional commit (9b5ee9aecbe2114dcaa667e7c6a8144f74e9ce2d) 
belonging to this JIRA which was accidentally committed under QPID-7753

> [Java Broker] Flow to disk if allocated direct memory exceeds broker wide 
> broker.flowToDiskThreshold
> 
>
> Key: QPID-7763
> URL: https://issues.apache.org/jira/browse/QPID-7763
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> Currently the broker.flowToDiskThreshold is compared against the size used by 
> messages on queues.
> However, the intent was to have a mechanism for preventing the broker going 
> out of direct memory. For this it is much more interesting to observe how 
> much direct memory the QpidByteBuffers use. The two numbers can easily differ 
> since the QBB can be sparsely populated. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7753) Sparsely occupied message buffers may lead to java.lang.OutOfMemoryError: Direct buffer memory

2017-05-22 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack commented on QPID-7753:


Commit 9b5ee9aecbe2114dcaa667e7c6a8144f74e9ce2d was intended for QPID-7763

> Sparsely occupied message buffers may lead to java.lang.OutOfMemoryError: 
> Direct buffer memory
> --
>
> Key: QPID-7753
> URL: https://issues.apache.org/jira/browse/QPID-7753
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: flow-to-disk-based-on-used-direct-memory-6-0-x.diff
>
>
> Some Broker usage patterns can lead to the Broker failing with a 
> "java.lang.OutOfMemoryError: Direct buffer memory" error.
> For the condition to manifest a producing application needs to use a single 
> connection for the production of messages. Some messages need to be consumed 
> quickly whilst others remain on the Broker. This pattern might result from:
> # the consuming application using message selectors to selectively consume 
> some messages whilst leaving others on the Broker.
> # the use of 'out of order' queue types (priority/sorted etc) where lower 
> priority items are left of the Broker.
> # the producing application routing messages to multiple queues and the 
> consuming application draining some queues but not others.
> The problem arises owing to the buffering strategy under the IO layer.
> {{NonBlockingConnection}} allocates a {{netInputBuffer}} from pooled direct 
> memory of size 256K.  This buffer is used for all network reads until the 
> space remaining in the buffer is less than the amount required to complete 
> the AMQP frame that is currently being read, in which case a new 
> netInputBuffer is allocated. The protocol layers identify the message 
> payload/message headers as part of AMQP frame parsing and create a 
> byte-buffer *views* onto the original input byte buffer.  This byte buffer is 
> retained by the store until the message is consumed.   In the usage pattern 
> described above, a single long lived message amongst a stream of shorted 
> lived messages causes an entire 256K buffer chunk to be retained.  Qpid 
> cannot dispose or reuse the buffer until it is entirely unoccupied.
> The flow to disk feature is designed to prevent excessive direct memory use 
> by flushing messages to disk if thresholds are breached.  Flow to disk does 
> not help the scenario described above because it considers the total payloads 
> of live messages.  Its algorithm does not consider direct memory occupancy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness

2017-05-22 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack commented on QPID-7605:


Rob pointed out to me that there is a relevant AMQP extension spec (currently 
working draft 2) here: 
https://www.oasis-open.org/committees/download.php/60516/amqp-soleconn-v1.0-wd02.pdf

Most of the points I raised above are covered by that spec. I raised 
https://issues.oasis-open.org/browse/AMQP-126 to have some points regarding the 
Sole Connection Detection Policy clarified.


> [Java Broker] [AMQP1.0] Container id uniqueness
> ---
>
> Key: QPID-7605
> URL: https://issues.apache.org/jira/browse/QPID-7605
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open 
> performative container-id is unique amongst existing established connections.
> As the JMS client id maps to the container-id, so this will fulfil the JMS 
> requirement.  
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String-
> Note that the Qpid JMS Client requires the Close performative with an Error 
> containing a hint to generate to correct JMS exception.  How will the Qpid 
> Broker know to do this?
> org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7775) Flow to disk should consider the size of the resident messages in memory.

2017-05-22 Thread Keith Wall (JIRA) 

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

Keith Wall commented on QPID-7775:
--

I think we should separate the frequency with which the Virtualhost runs flow 
to disk from the main housekeeping cycle.  To do this, we should use the normal 
pattern: virtualhost scoped context var backed by a derived attribute.

> Flow to disk should consider the size of the resident messages in memory.
> -
>
> Key: QPID-7775
> URL: https://issues.apache.org/jira/browse/QPID-7775
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Our current algorithm for triggering flow to disk has some shortcomings.
> * the algorithm does not account for memory returned by flow to disk.
> The decision to flow a message a newly arriving message to disk
> considers only the queue's target size and queue's depth.  Once a
> queue depth is over its target, all messages will go to disk even if
> all messages have actually been flowed to disk.  The same is true
> after recovery: flow to disk will be enabled even though there are no
> messages in RAM.
> * the fact that a queue's target size is assigned by periodically by
> housekeeping means that the queues target size can be wrong for most
> of the time.  This is very apparent if a queue is growing; you
> actually see *most* messages flowing to disk even when there is ample
> memory.  The target size is periodically recomputed but only remains
> correct for an instant, the queue returns to the flow to disk state as
> more messages are added.   We see this during perf test runs.
> We will change the MessageStore so that it tracks the size of the messages 
> that are held resident in memory.The flow to disk algorithm will be 
> change to by triggered when the resident memory exceeds the virtual host's 
> target size.
> This work is likely to fully replace the recent work done on QPID-7770.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (QPID-7775) Flow to disk should consider the size of the resident messages in memory.

2017-05-22 Thread Keith Wall (JIRA) 

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

Keith Wall reassigned QPID-7775:


Assignee: Keith Wall

> Flow to disk should consider the size of the resident messages in memory.
> -
>
> Key: QPID-7775
> URL: https://issues.apache.org/jira/browse/QPID-7775
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Our current algorithm for triggering flow to disk has some shortcomings.
> * the algorithm does not account for memory returned by flow to disk.
> The decision to flow a message a newly arriving message to disk
> considers only the queue's target size and queue's depth.  Once a
> queue depth is over its target, all messages will go to disk even if
> all messages have actually been flowed to disk.  The same is true
> after recovery: flow to disk will be enabled even though there are no
> messages in RAM.
> * the fact that a queue's target size is assigned by periodically by
> housekeeping means that the queues target size can be wrong for most
> of the time.  This is very apparent if a queue is growing; you
> actually see *most* messages flowing to disk even when there is ample
> memory.  The target size is periodically recomputed but only remains
> correct for an instant, the queue returns to the flow to disk state as
> more messages are added.   We see this during perf test runs.
> We will change the MessageStore so that it tracks the size of the messages 
> that are held resident in memory.The flow to disk algorithm will be 
> change to by triggered when the resident memory exceeds the virtual host's 
> target size.
> This work is likely to fully replace the recent work done on QPID-7770.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7793) [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming buffer contains a sequence of frames for the same channel

2017-05-22 Thread Keith Wall (JIRA) 

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

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

> [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming 
> buffer contains a sequence of frames for the same channel 
> --
>
> Key: QPID-7793
> URL: https://issues.apache.org/jira/browse/QPID-7793
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> If the incoming buffer contains an a sequence of frames for the same channel, 
> we currently call AccessController.doPrivileged for each frame individually.  
> As AccessController.doPrivileged is a relatively expensive operation, it is 
> worthwhile to make this algorithm more efficient.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (QPID-7793) [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming buffer contains a sequence of frames for the same channel

2017-05-22 Thread Keith Wall (JIRA) 

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

Keith Wall reassigned QPID-7793:


Assignee: Keith Wall

> [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming 
> buffer contains a sequence of frames for the same channel 
> --
>
> Key: QPID-7793
> URL: https://issues.apache.org/jira/browse/QPID-7793
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> If the incoming buffer contains an a sequence of frames for the same channel, 
> we currently call AccessController.doPrivileged for each frame individually.  
> As AccessController.doPrivileged is a relatively expensive operation, it is 
> worthwhile to make this algorithm more efficient.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (QPID-7790) Include statistics in API docs

2017-05-22 Thread Keith Wall (JIRA) 

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

Keith Wall reassigned QPID-7790:


Assignee: Keith Wall

> Include statistics in API docs
> --
>
> Key: QPID-7790
> URL: https://issues.apache.org/jira/browse/QPID-7790
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently statistics don't appear in the automated API docs.  We should add 
> them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7776) Add flow to disk queue policy

2017-05-22 Thread Keith Wall (JIRA) 

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

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

> Add flow to disk queue policy
> -
>
> Key: QPID-7776
> URL: https://issues.apache.org/jira/browse/QPID-7776
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> It should be possible to configure a queue so that enqueues are always flowed 
> to disk, or are flowed to disk when the queue reaches a certain length or 
> depth.
> A common use case for this would be a user who has one queue that is used 
> _store and forward_ (say for an end of day batch) whilst other queues are 
> used 'live'.  It will make sense for such a user for to mark the batch's 
> queue flow to disk.  That way the messages on the batch queue don't 
> needlessly clog the Broker's memory leaving it free for intraday work.
> The C++ Broker already has an analogous feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7790) Include statistics in API docs

2017-05-22 Thread Keith Wall (JIRA) 

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

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

> Include statistics in API docs
> --
>
> Key: QPID-7790
> URL: https://issues.apache.org/jira/browse/QPID-7790
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently statistics don't appear in the automated API docs.  We should add 
> them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (QPID-7776) Add flow to disk queue policy

2017-05-22 Thread Keith Wall (JIRA) 

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

Keith Wall reassigned QPID-7776:


Assignee: Keith Wall

> Add flow to disk queue policy
> -
>
> Key: QPID-7776
> URL: https://issues.apache.org/jira/browse/QPID-7776
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> It should be possible to configure a queue so that enqueues are always flowed 
> to disk, or are flowed to disk when the queue reaches a certain length or 
> depth.
> A common use case for this would be a user who has one queue that is used 
> _store and forward_ (say for an end of day batch) whilst other queues are 
> used 'live'.  It will make sense for such a user for to mark the batch's 
> queue flow to disk.  That way the messages on the batch queue don't 
> needlessly clog the Broker's memory leaving it free for intraday work.
> The C++ Broker already has an analogous feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7793) [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming buffer contains a sequence of frames for the same channel

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-7793: Perform contiguous frames for the same channel under the same access 
controller context


> [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming 
> buffer contains a sequence of frames for the same channel 
> --
>
> Key: QPID-7793
> URL: https://issues.apache.org/jira/browse/QPID-7793
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> If the incoming buffer contains an a sequence of frames for the same channel, 
> we currently call AccessController.doPrivileged for each frame individually.  
> As AccessController.doPrivileged is a relatively expensive operation, it is 
> worthwhile to make this algorithm more efficient.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7790) Include statistics in API docs

2017-05-22 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-7790: Add statistics to the online API documentation


> Include statistics in API docs
> --
>
> Key: QPID-7790
> URL: https://issues.apache.org/jira/browse/QPID-7790
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently statistics don't appear in the automated API docs.  We should add 
> them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPID-7793) [1.0] Avoid repetitious AccessController.doPrivileged calls if incoming buffer contains a sequence of frames for the same channel

2017-05-22 Thread Keith Wall (JIRA) 
Keith Wall created QPID-7793:


 Summary: [1.0] Avoid repetitious AccessController.doPrivileged 
calls if incoming buffer contains a sequence of frames for the same channel 
 Key: QPID-7793
 URL: https://issues.apache.org/jira/browse/QPID-7793
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.0.0


If the incoming buffer contains an a sequence of frames for the same channel, 
we currently call AccessController.doPrivileged for each frame individually.  
As AccessController.doPrivileged is a relatively expensive operation, it is 
worthwhile to make this algorithm more efficient.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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