And a one final question for today

Sep 5, 2012 at 5:03 AM


Why aren’t the queues and the exchanges of the RabbitMQ deleted after the corresponding Subscriber / Topic has been deleted? Is there some periodical purging, or am I missing something?

Thanks again, and have my apologies for the nitpicking.



Sep 5, 2012 at 5:49 AM

With the current implementation. UnSubscribe method does not interact with the client transport and do not do things such as queue clean up and deletion. The only thing the ESB does is try to do is create a queue when needed if it does not already exists. This logic only applies to transports that are queue and file based transport such as RabbitMQ, Redis, MSMQ, and FTP.

If I were to implement a logic that would try to interact with the client transport upon unsubscribe, it will be difficult because I have many other transport such as MSSQL, FTP, Email/SMTP, Tcp, and WCF NetTcp. They are not queue based, so it will be difficult to determine what to do with them upon unsubscribe.

To answer the question, it is some what possible but it is not ideal at this moment due to the nature of how each transport works.


Thanks for asking the question. It is a very good one :)

Sep 11, 2012 at 11:35 AM

So, what would be your recommendation as to how to deal with the inevitable accumulation of the dangling queues?

Another question: does the REST endpoint support transports other than the queue based ones?

Many 10x,



Sep 11, 2012 at 3:35 PM

If you are using a lot of queues in your application. I will assume that you are using management tools to make it easier to manage them. For example, if you are using RabbitMQ, then I will expect you to use the Management Plugin provided by RabbitMQ to monitor your queues and do any work such as purging unneeded queues. Same goes with a queue like MSMQ since you can use the window built-in tool to keep track of how your queues are been used.

The Rest Endpoint supports all the current transport in terms of been able to create a new subscriber and assign them a transport that would be used to receive messages.

Remember that Rest Endpoint is just a wrapper on top of the .NET API for the ESB, so it will by nature support the same communication transports. Means that if i call the subscribe method to subscribe to a topic using MSSQL and FTP transport. When ever a message is published, I will see the message in my MSSQL database table and we also see a file dropped in my FTP server containing the message that was sent. The other side of the coin is whether the PSB API provides a mechanism for reading it any of this transport all depends on what you are doing. The summary is below.

But In terms of calling the streaming method in the Rest endpoint, It is only capable of streaming data from TCP(Non-Queue Transport), RabbitMQ, Redis, MSMQ not because they are queuing transport but because I don't have any Streaming logic that stream data from FTP(How would one know which file to read without a specific identity), Email (Will need to read data using POP3, not a very straight forward implementation), MSSQL ( Not a good idea to poll a Database, User should write Trigger to do stuff in SQL when ESB Push data to it ), WebService( Can't Stream Web Service :) ) and the list goes on.

Thanks for asking another good question, I can use this to build up the wiki :)