* Pub Selection.
I'd like to propose two possible areas for the pubsub meet-up...
1. London Bridge / Borough
2. Spitalfields
What do people prefer? My preference is (1).
alexis
Bankside is the new Shoreditch which is the new Clerkenwell which is
the new ..... :-)
On Thu, Jun 3, 2010 at 3:34 PM, James Governor <jgov...@redmonk.com> wrote:
> Sod off with your sarf of the river bollocks. You know as well as I do
> that pubsub is a shoreditch phenomenon....
>
> I go for 2 of course.
I note that IGIndex is also just down the road here in Silicon Power Station.
On Thu, Jun 3, 2010 at 5:04 PM, James Governor <jgov...@redmonk.com> wrote:
> So its all about sucking on the big corporate tit now, is it?
You know London better than me, so your choice is fine for me.
-Alvaro
That would be spitalfields
On Jun 3, 2010 6:55 PM, "Alvaro Videla" <videl...@gmail.com> wrote:
I would like a place close to where the speaker dinner of Erlang Factory is.
You know London better than me, so your choice is fine for me.
-Alvaro
On Jun 3, 2010, at 4:32 PM, Alexis Richardson wrote: > And now we come to the important question o...
http://www.welovelocal.com/en/london/tower-hamlets/spitalfields/pubs/the-poet-bar-e17ez.html
For those coming from the sarf, probably the easiest thing is to cab it.
James, however, this does mean the first round is on you.
alexis
The docs read: If a message is published with the "mandatory" or "immediate" flags set, but cannot be delivered...
Should it read as: "Can not be delivered to the consumer" or "can not be routed to a queue"?
Thanks
Oleg
Hi Oleg.
Mandatory == must be delivered to a queue.
Immediate == must be delivered to a consumer.
Note that immediate really means immediate - if it can be delivered to a
queue, and a consumer is pulling things from that queue but not quickly
enough and messages are backing up in the server, that's not good enough.
Cheers, Simon
So what does 'must be delivered to the consumer means?'
a) handleDelivery(..) was successfully invoked.
b) consumer sent ACK.
c) consumer processes message transactionally and then commits it
Cheers
Oleg
Well, from the perspective of the server a) and b) are the same thing
(the server cannot be sure the client has seen the message unless it
sees an ack).
However, it looks like what we actually do is to consider it delivered
(for the purposes of the immediate flag but not any other) as soon as we
start to send the message to the consumer. Hmm.
If I have a consumer with noAck set to 'false', then I am sending the basicAck conditionally inside of the handleDelivery() method. This means that even though handleDelivery() was successfully invoked, the ACK might not have been sent, right?
Cheers
Oleg
From the perspective of the client, or of an all-knowing observer,
that's true. From the perspective of the server, suppose it delivers the
message and then the connection goes away - did the client crash or lose
power? Did it get as far as invoking handleDelivery() (or whatever the
client API looks like) or not?
The only way it'll know the client has processed the message
successfully is if it receives an ack.
But to return to the immediate flag, my "Hmm" in the last mail may have
been premature. The spec says:
"When a message arrives in a message queue, the message queue tries
immediately to pass it to a consumer application via AMQP. If this is
not possible, the message queue stores the message (in memory or on disk
as requested by the producer) and waits for a consumer to be ready. If
there are no consumers, the message queue may return the message to the
producer via AMQP (again, if the producer asked for this)."
I think the motivation for this behaviour is that if the server waited
for an ack, it could have to wait a long time.
Oleg
Yeah, I wouldn't really disagree with that. You could have some
requirement that you don't want messages to be buffered in the queue,
but, as you don't know the qos settings of any consumer, you have no way
of knowing what buffering the consumers are doing: by default, the
client buffers are unbounded. Furthermore, you have no knowledge of
whether the consumer was consuming with noAck set, in which case the
client really has responsibility for the future of the message, or if
the client is meant to be acking, in which case the server is still
maintaining responsibility.
About the only thing that you can gather from not getting a return when
using immediate is that the queue had an unblocked consumer. Of course,
you don't actually know whether you've not got a return - it may be
awaiting you in the future.
Matthew