Get(?timeout) doesn't block #36

Closed
haf opened this Issue Feb 17, 2012 · 6 comments

Comments

Projects
None yet
4 participants
Member

haf commented Feb 17, 2012

According to docs of Blocking Agent, it should block on get until something is available, and if nothing is then behaviour is undefined.

But docs say that it'll block.

Instead it throws TimeoutException.

I would prefer having Option<_> given, and then returning a None if the timeout expires, because afaik exceptions aren't the quickest way of handling flow control.

I'm using the project here:
https://github.com/mpsbroadband/MassTransit-AzureServiceBus/blob/integration/src/MassTransit.Async/Receiver.fs
https://github.com/mpsbroadband/MassTransit-AzureServiceBus/blob/integration/src/MassTransit.Transports.AzureServiceBus/InboundTransportImpl.cs

if you are interested in seeing it used IRL.

Contributor

panesofglass commented Feb 17, 2012

The name could/should probably be changed to BoundedBufferAgent as it doesn't truly block. Instead it prevents any additional data from being added to the queue until more is read; or inversely prevents reads until data is available. As for the timeout, that's built into the structure of the MailboxProcessor<_> and Async<_>. I'll look into what we could do to make the api less harsh.

Owner

tpetricek commented Feb 18, 2012

That's a tricky question. The Put method sends the message anyway (even if the timeout expires), so I'm not sure what's the best thing to do. Changing the agent to cancel the put operation when the timeout expires would make it a lot more complex. It shouldn't be difficult to add TryPut using PostAndTryAsyncReply but I don't think that leaving the value there would be an expected behaviour.

Regarding the name, the agent is essentially an asynchronous version of .NET BlockingCollection, so that's why it is called BlockingQueueAgent, so I think the naming makes sense, but BoundedBuffer sounds like a good name too.

Member

haf commented Feb 18, 2012

@tpetricek but I'm not trying to timeout the Put, but rather the Get...

Owner

tpetricek commented Feb 19, 2012

Hmm, I think Get is actually the same issue. As far as I know, when you send a message using PostAndTryAsyncReply, the message stays in the queue when the timeout expires, so the element will actually be removed from the queue (but the caller will not receive it, if the timeout expires).

This means that the fix would be a more notable change in the agent. It sounds like a pretty reasonable request, but it would probably make the implementation trickier.

Member

haf commented Feb 20, 2012

Ah, that does explain why I'm not getting my messages :) They are being removed behind the scenes. A big warning label on this should be in order right now.

Contributor

dsyme commented Mar 30, 2015

Closing this as the relevant code has moved to http://github.com/fsprojects/FSharpx.Async. Please reopen there if needed.

@dsyme dsyme closed this Mar 30, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment