Thanks for looking at this. I took a slightly different approach in my code that you might want to consider (see below), but I didn't post my fix because I think that lazy initialization of the consumers causes other problems, and I haven't had a chance investigate a better solution. Consider the case where 1000 messages are posted, and durable consumers are working through the backlog. If the server is restarted after 100 messages have been processed, the 900 other messages in the queue will just sit there until another message is posted. This seems like bad behavior. I think that it would be better if durable consumers were started at server startup rather than waiting for a REST call to trigger initialization.
If you still want to lazy initialize may I suggest that rather than synchronize the entire findQueue method, just synchronize on queues if queue == null. It does require a second null check inside the sychronized block because another thread could have completed initialization while the blocking thread waited for a lock. However, it does avoid sychronization for the majority of the calls to findQueue.
What are you thoughts?