I guess what was happening was that you sent a message to a queue successfully and the message expired after a while on the queue. A cleanup thread woke up and tried to find those expired messages then move them to DLQ queue but failed because either the DLQ queue was not properly authorized with the user or the cleanup thread somehow did not have right securityContext.
You might want to explicitely to add DLQ queue into "authorizationEntry" instead of ">" wildcard to see if it works.
If not, then it looks like a bug to me since the cleanup thread somehow did not have right securityContext. In this case, you might want to raise an ActiveMQ JIRA at Apache with a reproducible test case.
Just my 2c.
You have perfectly understood my issue. I tried what you suggested (explicit declaration of my DLQ queue in the authorizationEntry section) but I still end up with the same security exception.
So maybe it could be a bug. I will try to gather all the needed stuff to easily reproduce that and fill a JIRA.
I've just opened a JIRA:
This issue has been confirmed to be a bug. It will be fixed in ActiveMQ 5.3.1/5.4.0 (refer to JIRA details).
Edited by: concombre masqué on Nov 27, 2009 8:45 AM
Did you happen to find a work-around for 5.3.0? Since 5.3.1 for fuse is not out, it would be helpful if I had a way to move messages to the DLQ without this error occurring.
FYI, the fix for this issue is included in FUSE Message Broker 5.3.0-psc-01-00RC1 (see release notes here: http://fusesource.com/wiki/display/ProdInfo/FUSE+Message+Broker+v5.3.0-psc-01+Release+Notes).
Moreover this release of FUSE Message Broker is provided with the latest FUSE ESB release (FUSE ESB 4.1.0-psc-01-00RC1).