[
https://issues.apache.org/jira/browse/AMQ-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662345#comment-16662345
]
Gary Tully commented on AMQ-6690:
---------------------------------
[~nopius]
that is not good, for some context; there were related problems with duplicate
detection and concurrency. Some folks were hitting the jmx operation in
parallel with large queues and the stats were all over the place. When the
duplicate detection is in place (as it is by default), the audit will catch
every resend as a duplicate.
When I looked at the code is was clear that moving to the same destination was
never considered. Hence my move to clarify the behaviour.
see: https://issues.apache.org/jira/browse/AMQ-6703 which has a test for move,
purge move back.
That approach will work fine post 5.15.0
For the journal, there is ack compaction that will allow log files to get
reclaimed out of sequence. That may also help.
If you really need the ability to moveToSameDest there is some work to do to
have it work reliably.
> Protect against JMX move/copy operations onto self
> --------------------------------------------------
>
> Key: AMQ-6690
> URL: https://issues.apache.org/jira/browse/AMQ-6690
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMX
> Affects Versions: 5.14.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Fix For: 5.15.0
>
>
> The move and copy jmx operations are intended to move/copy messages to
> another destination. However this is not enforce and if the move/copy
> destination is the same queue the logs fill with duplicate warnings etc and
> the stats can get out of sync if the operation is repeated or concurrent.
> Best to cut this off at the pass with a return return code indicating nothing
> was moved/copied.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
