[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526264#comment-15526264
]
Rob Godfrey commented on QPID-7379:
-----------------------------------
{quote}
I was under the impression that qpid.max_message_size is a mechanism to
(amongst other things) prevent a broker from going OOM due to large messages
exceeding memory limitations. Would it then not make sense to reject message
stores with large messages instead of accepting them and then crashing with OOM?
{quote}
The existence of messages in the store that are greater in size than the
current max message size could also be caused by a later reduction of the max
message size after a message had previously been deemed acceptable. I think we
should treat the extract in the same way that we would the underlying store -
the underlying store may contain arbitrarily large messages, and we would just
accept them.
{quote}
What I meant was on serialisation we could copy the data from the message
directly to the output stream without first copying it to the interal _content
field by holding on to a reference to the StoredMessage in the constructor. I
did not appreciate the deserialisation path where this does not seem possible
and then the additional complication is probably not worth it.
{quote}
I think the best approach here would be to change the interface of record to
maybe write to an OutputStream-like object - I have made this change in my
latest commit
> [Java Broker] Provide a mechanism to extract messages from a vhost message
> store and replay them into a new vhost
> -----------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but
> there are not currently any mechanisms to extract the contents of the message
> store and replay that into a new vhost. We should add this feature to (for
> example) allow people to migrate their data from one vhost type to another
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
