[
https://issues.apache.org/jira/browse/QPID-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057413#comment-16057413
]
ASF subversion and git services commented on QPID-7791:
-------------------------------------------------------
Commit 894c0b644f98f948e5cc245b3ad483a295287171 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=894c0b6 ]
QPID-7791: Ensure that threads used by the recoverer dispose thread-locally
cached QBBs
Cherry picked from 95ee1329cdc9b2a3c5fb0903bb61105b14eb2f37. Conflicts
resolved by hand and source downgraded back to JDK 1.7
> Recover metadata into direct memory
> -----------------------------------
>
> Key: QPID-7791
> URL: https://issues.apache.org/jira/browse/QPID-7791
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0, qpid-java-6.1.4, qpid-java-6.0.8
>
>
> Currently, the message store on reading of the metadata creates heap buffers
> rather than direct. This code path is used by both recovery and re-reading
> metadata following a flow to disk.
> This approach means that the Broker footprint differ: If messages come in on
> the wire, content and metadata (at least initially, is in direct), if
> messages are recovered, metadata is in heap. This makes giving advice
> around the size of Qpid's memory more difficult. If the user makes poor
> choice a situation is possible where the Broker may not be restartable
> because there is too little heap to recover all the metadata.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
