[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15574852#comment-15574852 ] ASF subversion and git services commented on QPID-7379: --- Commit 1764849 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1764849 ] QPID-7379 : Revert renaming of extractConfig > [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 > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15574835#comment-15574835
]
Lorenz Quack commented on QPID-7379:
I just came across another issue that had escaped my review before:
{{VirtualHost#extractConfig}} was renamed to {{exportConfig}}.
This has three issues:
* It breaks backwards compatibility
* If we go forward with the rename then probably {{Broker#extractConfig}}
should also be renamed
* This broker the WMC which still calls {{extractConfig}} in {{VirtualHost.js}}
> [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: Lorenz Quack
> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532677#comment-15532677 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762761 from [~lorenz.quack] in branch 'java/trunk' [ https://svn.apache.org/r1762761 ] QPID-7379: [Java Broker] Fix compilation issue > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532649#comment-15532649 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762760 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1762760 ] QPID-7379 : address review comment on filename for export > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532586#comment-15532586 ] Lorenz Quack commented on QPID-7379: I hate to say it but you left the two %09d string format markers from the message number in the format string. Also there is no "." to separate the filename from the extension. > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532497#comment-15532497 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762755 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1762755 ] QPID-7379 : address review comment on filename for export > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532459#comment-15532459
]
Lorenz Quack commented on QPID-7379:
I'm afraid the last commit is not doing the right thing.
According to Appendix D of RFC 6266 on should not use non-ASCII (together with
some other restrictions) in the filename of the Content-Disposition header.
If there are non-ASCII characters one should replace or remove them and add a
"filename*" (notice the star at the end) field.
I suggested to look at {{AbstractQueue$MessageContent}} (actually it is now in
{{AbstractQueue$BaseMessageContent#getContentDisposition}}) which tries to take
care of all of this. Ideally we would share the code.
> [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: Lorenz Quack
> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532238#comment-15532238 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762749 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1762749 ] QPID-7379 : address review comment on filename for export > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529815#comment-15529815 ] Lorenz Quack commented on QPID-7379: Looks good! I like the change of passing the serialiser into the Records instead of returning byte[]. One comment has not been addressed so far: * The Content-Disposition should also use the extended "filename*" syntax for UTF-8 encoded filenames. (See AbstractQueue$MessageContent) > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529203#comment-15529203 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762630 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1762630 ] QPID-7379 : fix test to use "exportMessageStore" > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528975#comment-15528975 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762621 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1762621 ] QPID-7379 : fix writeInt bug in previous commit, and rename "extractMessageStore" to "exportMessageStore" > [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: Lorenz Quack > 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526268#comment-15526268
]
Rob Godfrey commented on QPID-7379:
---
{quote}
extraction and import of message store happens in the http thread rather than
the config thread meaning it could race with other operations (including
another import/export, reactivation of the VHost, etc.).
{quote}
I believe we are going to find a more generic solution for this so I have no
yet addressed this concern here
> [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: Lorenz Quack
> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526263#comment-15526263 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762490 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1762490 ] QPID-7379 : Address review comments > [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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15522944#comment-15522944
]
Rob Godfrey commented on QPID-7379:
---
{quote}
* AbstractVirtualHost#importMessageStore can be used for a DoS attack by
crafting a "store" containing just 5 bytes: "0x00 MAX_INT" which will allocate
a byte array of 2 GB which potentially exhaust the broker's heap bringing down
the broker with an OOM Error. Maybe we limit the version string length to 1
byte? In that case the arbitrary 50 in data.mark(50) could be replaced with an
accurate upper bound on the reads like 1+1+256. I guess a similar DoS can be
performed at many point within the serialisation stream. I think we should
guard against this by disallowing deserialisation of messages that exceed
qpid.max_message_size.
{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 believe the 0 that is expected at the beginning of
AbstractVirtualHost#importMessageStore is actually a
serializer.v1.RecordType#VERSION
{quote}
No - the text in the comment is an accurate reflection of how I believe it
should be interpreted... all future versions must also begin "0"
. For the v1 format this also looks
like a standard record, but that can be considered coincidence.
{quote}
* It might be nicer to just throw the data stream at all serializers that are
available through the QpidServiceLoader and have them handle or reject the data
instead of putting knowledge of the serialisation format into the
AbstractVirtualHost
{quote}
I think the "correct" change would be to extract this logic into some sort of
MessageStoreSerializerFactory or something - but I'm against just throwing the
data stream at the serializers. Really in order to be able to reset to the
start the information necessary to determine the format needs to be in some
sort of header at the start.
{quote}
* Why do you use arrays instead of direct memory? This seems especially odd for
potentially large chunks like the message content. Also, is it necessary to
make an private copy the data in the MessageRecord? Could you not just copy it
from the storedMessage in MessageRecord.getData()?
{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.
All the other points seem valid and I agree should be fixed
> [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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516682#comment-15516682 ] Keith Wall commented on QPID-7379: -- End to end test case added verifying a message store containing a message can be extracted/imported with fidelity. I have no further review comments to add. > [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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1551#comment-1551 ] ASF subversion and git services commented on QPID-7379: --- Commit 1762067 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1762067 ] QPID-7379: [Java Broker] Add ent to end test for new feature > [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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[
https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493794#comment-15493794
]
Lorenz Quack commented on QPID-7379:
WIP Review:
* The Content-Disposition should also use the extended "filename*" syntax for
UTF-8 encoded filenames. (See {{AbstractQueue$MessageContent}})
* {{AbstractVirtualHost#importMessageStore}} can be used for a DoS attack by
crafting a "store" containing just 5 bytes: "0x00 MAX_INT" which will allocate
a byte array of 2 GB which potentially exhaust the broker's heap bringing down
the broker with an OOM Error. Maybe we limit the version string length to 1
byte? In that case the arbitrary {{50}} in {{data.mark(50)}} could be replaced
with an accurate upper bound on the reads like {{1+1+256}}. TODO: check whether
other parts of the deserializer are equally vulnerable.
* I believe the {{0}} that is expected at the beginning of
{{AbstractVirtualHost#importMessageStore}} is actually a
{{serializer.v1.RecordType#VERSION}}
* It might be nicer to just throw the data stream at all serializers that are
available through the QpidServiceLoader and have them handle or reject the data
instead of putting knowledge of the serialisation format into the
{{AbstractVirtualHost}}
> [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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452223#comment-15452223 ] Keith Wall commented on QPID-7379: -- Automated test case to be added and review. > [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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost
[ https://issues.apache.org/jira/browse/QPID-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408595#comment-15408595 ] ASF subversion and git services commented on QPID-7379: --- Commit 1755238 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1755238 ] QPID-7379 : Allow extract and import of message store contents > [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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
