Link: Added: This issue depends JBMESSAGING-1368

I'd suggest adding a note about this to documentation because the solution is not so obvious.

The definite problem solution is to delete the row from JBM_POSTOFFICE.

Please could you have a look on this?

Martin - is this a new problem in CP02? (In other words, is this a regression relative to CP01/GA?)

Affects: Added: [Release Notes]

Release note content under known issues

"BMESSAGING-1368 - If you have deployed a clustered queue and then undeploy it, you cannot deploy a non-clustered queue with the same name.  You must delete the destination from JBM_POSTOFFICE table first before redeploying"

added to 4.3 release notes

Cannot verify this fix with IR5 since the docs package is not correct and doesn't contain release notes (SOA-889).

I suggest the following update to the rel. notes (marked with >>> <<<):

You cannot deploy a non-clustered queue with the same name as a clustered queue that has been
deployed >>>and<<< then undeployed >>>and vice versa<<<. You must delete the destination from JBM_POSTOFFICE table first
before deploying.

to clarify:

if I deploy a clustered queue called X, undeploy it,and then deploy a new clustered queue called X there are no problems ?  And like wise if the queue each time is not clustered?

its only a problem if the clustering "mode" of the queue differs?

Unfortately I can't use phrases like "vice versa" because they don't translate well.

New content:

Once a queue is undeployed you cannot deploy a new queue with the same
name if one of the queues was a clustered queue and the other queue was 
not.  You must delete the destination from the JBM_POSTOFFICE table 
before the new queue can be deployed successfully.

content update applied

This seems really great.

Verified in GA