﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Maninder Batth commented on Queuing Systems</title><description>@Ayende,
  
"This is a failure scenario, where the first consumer has failed"
  
&gt;&gt; That is one possible scenario, other could be where the first consumer Really processed the message, but took longer than timeout. As we are not using distributed transactions, there could be actual work committed to the db.
  
In this case, second consumer may actually fail.
</description><link>http://ayende.com/4678/queuing-systems#comment19</link><guid>http://ayende.com/4678/queuing-systems#comment19</guid><pubDate>Wed, 03 Nov 2010 20:01:12 GMT</pubDate></item><item><title>Ayende Rahien commented on Queuing Systems</title><description>Maninder,
  
a) this is typical for remote queues.
  
b) this is a failure scenario, where the first consumer has failed
</description><link>http://ayende.com/4678/queuing-systems#comment18</link><guid>http://ayende.com/4678/queuing-systems#comment18</guid><pubDate>Wed, 03 Nov 2010 19:34:29 GMT</pubDate></item><item><title>Maninder Batth commented on Queuing Systems</title><description>@Ayende,
  
I said "And if multiple processes are connected to same queue, it is also possible for multiple consumers to consume the same message under certain conditions."
  
The key is "under certain conditions".
  
So if there are multiple processes on the host machine, picking up messages from the local queue, then it is possible under the model of "Client Acknowledgement" as opposed to  "Auto Acknowledgement" that the consuming process could not respond with ACK, within timeout period and hence, queuing system put the message back on the queue , which gets picked by the second consumer. Hence, multiple consumer , under certain conditions can process the same message even on a local queue scenario.
</description><link>http://ayende.com/4678/queuing-systems#comment17</link><guid>http://ayende.com/4678/queuing-systems#comment17</guid><pubDate>Wed, 03 Nov 2010 19:30:35 GMT</pubDate></item><item><title>Ayende Rahien commented on Queuing Systems</title><description>Maninder,
  
Even in the same process, things can fail. For example HD space might have run out.
  
But in general, when speaking about such things, it is common to think of a single machine as a single unit.
  
In the same sense that you are composed of a complex system of organs working together, but you consider yourself a single entity.
  
  
And I am not aware of a single queuing impl. that would let multiple consumers consume the SAME message. Note that there are things like topics, streams and exchanges, but that isn't what I am talking about here.
  
</description><link>http://ayende.com/4678/queuing-systems#comment16</link><guid>http://ayende.com/4678/queuing-systems#comment16</guid><pubDate>Wed, 03 Nov 2010 17:58:01 GMT</pubDate></item><item><title>Maninder Batth commented on Queuing Systems</title><description>@Ayende,
  
I am unclear on your consequences around local queue.
  
&gt;&gt; Local queue is always going to be available – in other words: queue.Send()  cannot fail.
  
My understanding is that a Local Queue is Local to the machine and not the process. Hence, based on the client implementation of Local Queue and the underlying operating system, you could use tcp. If for example the host system runs out of file descriptors, the send() and receive for local can fail also.
  
  
&gt;&gt; Only one consumer can process a message.
  
You can have multiple processes connected to a local queue on the same machine. And if multiple processes are connected to same queue, it is also possible for multiple consumers to consume the same message under certain conditions.
  
  
&gt;&gt;There is a lot of state held locally.
  
State is held in the queuing system and not the processing system. Irrespective of remote or local, the state will be held. Also based on queue system implementation, you can design for failovers.
  
  
  
  
</description><link>http://ayende.com/4678/queuing-systems#comment15</link><guid>http://ayende.com/4678/queuing-systems#comment15</guid><pubDate>Wed, 03 Nov 2010 17:53:14 GMT</pubDate></item><item><title>brian z commented on Queuing Systems</title><description>@Ayende
  
  
"it is important to run the distributor on a cluster configuring its queues as clustered resources"
  
  
We're looking at the definition of a local queue differently.  You listed 5 things in your article that distinguish a local queue from a remote queue - I thought that a queue configured as a clustered resource would meet those requirements.
</description><link>http://ayende.com/4678/queuing-systems#comment14</link><guid>http://ayende.com/4678/queuing-systems#comment14</guid><pubDate>Mon, 01 Nov 2010 14:09:05 GMT</pubDate></item><item><title>e4s3 commented on Queuing Systems</title><description>Ayende, u should really have a look into ZooKeeper(
[http://hadoop.apache.org/zookeeper/](http://hadoop.apache.org/zookeeper/)), 
  
It is not just queue, but have more features that the other lacking.., and probably could give u some idea
  
</description><link>http://ayende.com/4678/queuing-systems#comment13</link><guid>http://ayende.com/4678/queuing-systems#comment13</guid><pubDate>Mon, 01 Nov 2010 03:28:13 GMT</pubDate></item><item><title>Ayende Rahien commented on Queuing Systems</title><description>Brian,
  
Yes, it does.
  
The distributer simply split the process into several steps, each of them assumes a local queue.
</description><link>http://ayende.com/4678/queuing-systems#comment12</link><guid>http://ayende.com/4678/queuing-systems#comment12</guid><pubDate>Sun, 31 Oct 2010 16:27:41 GMT</pubDate></item><item><title>brian z commented on Queuing Systems</title><description>NServiceBus doesn't always assume the queue you have is a local one:
  
[http://www.nservicebus.com/Distributor.aspx](http://www.nservicebus.com/Distributor.aspx)</description><link>http://ayende.com/4678/queuing-systems#comment11</link><guid>http://ayende.com/4678/queuing-systems#comment11</guid><pubDate>Sun, 31 Oct 2010 14:49:21 GMT</pubDate></item><item><title>Bryan commented on Queuing Systems</title><description>@Jeff
  
  
AMQP (specifically RabbitMQ) have great .NET support these days. ZeroMQ also looks like it has a lot of potential buti have yet to try it. 
</description><link>http://ayende.com/4678/queuing-systems#comment10</link><guid>http://ayende.com/4678/queuing-systems#comment10</guid><pubDate>Sun, 31 Oct 2010 01:19:16 GMT</pubDate></item><item><title>Jeff commented on Queuing Systems</title><description>It's a bummer .NET doesn't have a decent native messaging solution like java does (JMS implementations abound). MSMQ is a sorrow excuse for an enterprise messaging solution IMO.
  
  
Apache.NMS (
[http://activemq.apache.org/nms.html](http://activemq.apache.org/nms.html)) provides a decent client for .NET interaction with ActiveMQ. I have been using it quite a bit lately and rocks. It supports all the major features of JMS including transactions, durable consumers, topics, queues, different ack modes and so on and so forth.
</description><link>http://ayende.com/4678/queuing-systems#comment9</link><guid>http://ayende.com/4678/queuing-systems#comment9</guid><pubDate>Sat, 30 Oct 2010 23:08:26 GMT</pubDate></item><item><title>Scooletz commented on Queuing Systems</title><description>Ayende, you mentioned Amazon SQS. Can you deploy local queues in a cloud? Is it only a cost of deploying a queuing system or maybe mismatch in paradigms?
</description><link>http://ayende.com/4678/queuing-systems#comment8</link><guid>http://ayende.com/4678/queuing-systems#comment8</guid><pubDate>Sat, 30 Oct 2010 19:26:42 GMT</pubDate></item><item><title>Stacy commented on Queuing Systems</title><description>Have you taken a look at Sql Service Broker?  You get transactions (msg + database activity), and free remoting with Sql Express.
</description><link>http://ayende.com/4678/queuing-systems#comment7</link><guid>http://ayende.com/4678/queuing-systems#comment7</guid><pubDate>Sat, 30 Oct 2010 16:38:43 GMT</pubDate></item><item><title>Sean Kearon commented on Queuing Systems</title><description>@Dennis - the Quartz.NET project (
[http://quartznet.sourceforge.net/](http://quartznet.sourceforge.net/)) is a scheduler for .Net, if that suits your needs.
</description><link>http://ayende.com/4678/queuing-systems#comment6</link><guid>http://ayende.com/4678/queuing-systems#comment6</guid><pubDate>Sat, 30 Oct 2010 16:28:13 GMT</pubDate></item><item><title>Dennis commented on Queuing Systems</title><description>What about scheduling system for csharp? Almost any major website can use that for doing some work at some specific time. 
</description><link>http://ayende.com/4678/queuing-systems#comment5</link><guid>http://ayende.com/4678/queuing-systems#comment5</guid><pubDate>Sat, 30 Oct 2010 14:23:56 GMT</pubDate></item><item><title>Bryan commented on Queuing Systems</title><description>@Bill
  
  
You need to either make your messages indempotent or have some sort of tracking system (such as a database) to keep an eye out for duplicates.  Any other approach I've tried has not worked out well. 
</description><link>http://ayende.com/4678/queuing-systems#comment4</link><guid>http://ayende.com/4678/queuing-systems#comment4</guid><pubDate>Sat, 30 Oct 2010 13:18:13 GMT</pubDate></item><item><title>Bill commented on Queuing Systems</title><description>yes, thats one way of doing it but as you mention is not a real transaction i.e not 100% reliable. Its an interesting problem since the tradeoffs are performance for transactional safety.
  
  
There are some java solutions which look good but I am not sure about their performance compared to msdtc. I have for a while thought about looking in to java queuing and transactions since the options on the Microsoft side are limited.
</description><link>http://ayende.com/4678/queuing-systems#comment3</link><guid>http://ayende.com/4678/queuing-systems#comment3</guid><pubDate>Sat, 30 Oct 2010 12:12:35 GMT</pubDate></item><item><title>Ayende Rahien commented on Queuing Systems</title><description>Bill,
  
Generally, remote queuing systems can't really take part of a real transaction.
  
Mostly because it costs too much.
  
What you can do is set the timeout for a very long time, and ack on the transaction commit.
</description><link>http://ayende.com/4678/queuing-systems#comment2</link><guid>http://ayende.com/4678/queuing-systems#comment2</guid><pubDate>Sat, 30 Oct 2010 11:08:54 GMT</pubDate></item><item><title>Bill commented on Queuing Systems</title><description>Interesting, I was just doing some work with MSDTC and MSMQ remote queues. With the poison message scenario you describe (as an alternative to MSDTC) how would rollback be handled in the case of a larger transaction? What if there was a db operation and a queue operation that needed to be transactional but the db operation failed on commit? It seems like the poison message method only works if you are only using a message queue and nothing else is taking part in the transaction?
  
  
Would be interested to know if those scenarios are handled as they are quite common in large scale non trivial systems which is where MSDTC is of use.
</description><link>http://ayende.com/4678/queuing-systems#comment1</link><guid>http://ayende.com/4678/queuing-systems#comment1</guid><pubDate>Sat, 30 Oct 2010 10:42:44 GMT</pubDate></item></channel></rss>