[rabbitmq-discuss] Subscription Pattern in .net

Tue Mar 15 20:31:07 GMT 2011

>
>  IEnumerator.MoveNext() currently waits an indefinite amount of time until
>> a message arrives. If I understand correctly, you want a version of with a
>> timeout, supplied in the constructor.
>>
>> Would the enumeration need to be restartable? You may need a different
>> implementation of Reset() in that case and this substantially changes the
>> semantics of Subscription. I'm not sure how well this fits with IEnumerator.
>> Your use-case appears to be reading messages until a large gap appears
>> between message. At first glance that looks insufficiently general to
>> justify changing the IEnumerator implementation.
>>
>> The Next(TimeOut,out Msg) method was intended to meet your needs if you
>> want a timeout. The example you provided using this looks fine.
>
>
The goal was finer-grained control, while trying to hide detail.  This is
slightly unrelated, but it looks to me as though there are a few rough edges
we could sand back.  e.g. channel has a "CreateBasicProperties" method that
we can use in BasicPublish.  No big deal, but BasicPublish could have an
overload which creates its own properties, as this method knows its context
already (i.e. the method is in Channel, so go create your own basic
properties, basicPublish!!)

No reset required for the enumerator.

The context is: A. send off a bunch of messages asynchronously, and B. wait
for a reply.  C. If messages don't turn up in a reasonable period of time,
stop waiting.  If the messages do turn up, good, continue.  In essence, I'm
replicating the "Join" that you use after threading off a list of tasks, but
via messaging.

I know there are heavier-duty implementations such as remote method
invocation over RabbitMQ, but this approach seemed simpler to me.  Perhaps a
whole new pattern should be created for this need.  At the moment I'm using
the slightly less elegant method that you mentioned.  It doesn't really get
in the way that much.  However, being in a community that has helped out, I
thought, hmmm... maybe i could at least return the favour in a small way.

>
> So what is the policy on updating the Mercurial repository?
>>
>
> You could also fork our github repository here:
> https://github.com/rabbitmq/rabbitmq-dotnet-client
> This would be a way of building consensus for your proposal.
>
> Code that you contribute that does get accepted in the main mercurial
> repository will need a signed contributor agreement.
>
>
> Regards
>
> Emile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110315/1dfbb1b9/attachment.htm>