[rabbitmq-discuss] WCF and queue creation

[Emile Joubert]

Hi,

This feature was not added at the time, but since there appears to be
demand for it I will file a bug. If you wish to try the same workaround
that was discussed before then you will need to edit line 153 in
RabbitMQInputChannel:

http://hg.rabbitmq.com/rabbitmq-dotnet-client/file/130a3f3dfa51/projects/wcf/RabbitMQ.ServiceModel/src/serviceModel/RabbitMQInputChannel.cs#l153


Emile


On 17/08/11 18:15, rjrizzuto wrote:
> 
> We're also considering moving from MSMQ via WCF to RabbitMQ via WCF.  If I
> follow this discussion correctly, we also need durable queues.  I.e. we want
> to be able to stop and restart either the producer or consumer without
> losing data or the queue going away.  Would we need to apply the same patch
> to line 171 in RabbitMQInputChannel, or is that now included in the current
> version?
> 
> 
> Emile Joubert-2 wrote:
>>
>>
>> Hi Jonathan,
>>
>>
>> On 11/06/10 16:18, Jonathan Graham wrote:
>>> Hi Emile,
>>
>>
>>> I have two WCF services (let's call them A and B) in an existing
>>> application.  I want to send asynchronous, one-way messages from service
>>> A to service B.  The operation being invoked on service B can take some
>>> time to complete, and service A's call to B is due to an end user
>>> initiated operation on A. I don't want to make end users wait for B to
>>> complete, hence the asynchronous requirement.  Service B is also a
>>> little fragile and is not always available, so I want any messages sent
>>> to it to be stored in a durable queue until B is able to process the
>>> messages.
>>
>> I agree that a one-way (fire & forget) channel is appropriate for your 
>> use case. Queue durability alone will not be sufficient to accomplish 
>> your goal though, because the service host will need to reconnect to the 
>> same queue. If you are comfortable with recompiling the ServiceModel 
>> project in order to experiment with a possible approach, try replacing 
>> line 171 in RabbitMQInputChannel with:
>>
>> string queue = m_model.QueueDeclare(LocalAddress.Uri.AbsolutePath, true);
>>
>> This will cause the service queue to have a fixed name and be durable. 
>> The queue will then accumulate requests in the event of service B 
>> temporarily disconnecting.
>>
>> Caveats apply: This code has not been through our formal QA process. It 
>> is meant for experimentation only and may break other things.
>>
>>> [...] Unfortunately because Rabbit's WCF
>>> binding doesn't let us use durable queues, we haven't yet been able to
>>> make use of it.
>>
>> This is a feature that could be added if there was sufficient demand, 
>> but you are the first to suggest it.
>>
>>> It looks like the following options are available:
>>>
>>> 1. Change the way the WCF binding works so that existing queues can be
>>> used and/or that queues declared by the binding can be made durable. (As
>>> an aside, if I can find the time, I wouldn't mind contributing this
>>> change, but I don't have a whole lot of free time at present.)
>>
>> I'm hoping that the line of code above gives you a useful place to 
>> start. I'd be interested to know if it works for you.
>>
>>> 2. No longer implement service B as a WCF service and instead use the
>>> RabbitMQ .NET client API to consume messages from RabbitMQ.
>>
>> If you are not bound to the strictures of WCF then this can work very 
>> simply. There are many examples in the RabbitMQ.Client.Examples that 
>> illustrate how to send messages from a message producer to a consumer. 
>> You will need to do some of the work that RabbitMQ ServiceModel does for 
>> you, such as declaring and binding a queue and structuring the message 
>> in the way that the consumer can understand it.
>>
>> Regards
>>
>> Emile
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>>
> 


-- 
Emile Joubert

RabbitMQ
SpringSource, a division of VMware
VMware