[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525779#comment-15525779
]
Lorenz Quack commented on QPID-7379:
------------------------------------
{quote}
I think anyone who has sufficient privileges to import a data store probably
also has all sorts of other ways to bring down the broker. I think the issue
with qpid.max_message_size is that we don't know that the source host had the
same or smaller limit. Overall I don't see this as a priority.
{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}
OutputStreams only work with byte[], not ByteBuffers which means heap memory
has to be used. I don't believe (given the prior constraint) that any
unnecessary copy is made... on reading the record we read the bytes into an
array from the output stream. On writing we create an array and copy the data
from the content into the array. This value is then written to the outputstream.
{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.
> [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]
