[rabbitmq-discuss] Using rabbitmq-http2 (was: simple.publish over the JSON RPC interface)

Fri Aug 14 18:35:54 BST 2009

Hi Tony,

On Tue, Aug 11, 2009 at 9:04 PM, Tony Garnock-Jones<tonyg at lshift.net> wrote:
> Nathan Gray wrote:
>> It seems to me that there's no one-size-fits-all timeout for poll.
>> Some apps will want non-blocking polling and others will want it to
>> block indefinitely until there's work to do.  Wouldn't it be better to
>> just have an explicit timeout parameter to poll()?
>
> Yes, but that makes the timeout-maintaining code in the channel object
> much more complex. Generally, channel *instances* are not shared between
> applications, so each app is still free to set sessionTimeout according
> to its needs. One app could set it to half an hour (and get
> corresponding 15-minute poll() cycles), another to 30s. The current
> setup lets all parallel poll()s on a single instance (if there's more
> than one) be treated identically; a timeout parameter to each poll()
> would require a separate timer on the server-side for each. Ultimately
> though, if the way it's currently being done is shown to be a problem,
> it's totally changeable.

Fair enough.  I'll wait to see if this causes any real trouble in my
app before I call it a problem.

> Adding a *non*-blocking variant of poll() is an interesting idea. I
> hadn't thought anyone would want that! Is it something you would use?

I haven't actually implemented my system yet, so I can't say if I'd
use it or not.  Probably not in this system, but it seems like a
natural thing to have.  But look, I'm just an application programmer.
I'm not much of a network programmer, much less an enterprise
messaging connoisseur.  My design advice should definitely be taken
with a grain of salt.  ;^)

Cheers,
-n8

-- 
http://n8gray.org