[rabbitmq-discuss] June 9th - Meetup in London

[Alexis Richardson]

Right

Let's organise this...

Beers on Wednesday June 9th starting at ... 5:30pm?

Location?

alexis




On Wed, May 12, 2010 at 12:22 PM, Alvaro Videla <videl...@gmail.com> wrote:
> That's OK for me, since I'll be arriving in the morning
>
>
> On May 12, 2010, at 7:09 PM, Alexis Richardson wrote:
>
>> On Wed, May 12, 2010 at 12:05 PM, James Governor <jgov...@redmonk.com> wrote:
>>> Pub sub. Lets pick it up. Les plans diaboliques.
>>
>> Merveilleux.
>>
>>
>>
>>
>>> When in june?
>>
>> Do as the junians do?
>>
>> I suggest Wednesday June 9th.
>>
>> alexis
>>
>>
>>>
>>>
>>> -----Original Message-----
>>> From: alexis.r...@gmail.com [mailto:alexis.r...@gmail.com] On
>>> Behalf Of Alexis Richardson
>>> Sent: 12 May 2010 11:59
>>> To: Alvaro Videla
>>> Cc: rabbitmq-discuss; James Governor; Jonathan Lister
>>> Subject: Re: [rabbitmq-discuss] Meeting in London
>>>
>>> Alvaro
>>>
>>> That sounds like an excellent plan.  Perhaps it's time for another
>>> 'pubsub' meet-up?  If it is the week of the EF then we can invite a
>>> lot of 'NoSQL' folks along too...
>>>
>>> alexis
>>>
>>>
>>> On Wed, May 12, 2010 at 10:08 AM, Alvaro Videla <videl...@gmail.com>
>>> wrote:
>>>> Hi guys/gals,
>>>>
>>>> I'll asked Alexis about this and he told me to ask here:
>>>>
>>>> I'll be in London next June for the Erlang Factory. Since I'm traveling
>>> from China and I won't be going there any time like every week :) I would
>>> like to meet with some of the RabbitMQ guys in London, can we arrange
>>> something?
>>>>
>>>> Perhaps going to a pub or something?
>>>>
>>>> Regards,
>>>>
>>>> Alvaro
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq...@lists.rabbitmq.com
>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>>
>>>
>
>

_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

--
You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group.
To post to this group, send email to rabbitmq...@googlegroups.com.
To unsubscribe from this group, send email to rabbitmq-discu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rabbitmq-discuss?hl=en.

[Alvaro Videla]

For me it' ok too, just let me know the details

-Alvaro


On May 26, 2010, at 1:01 AM, Jonathan Lister wrote:

> Sounds good to me.

> --
> t: @jayfresh
> b: http://www.jaybyjayfresh.com

[Alexis Richardson]

And now we come to the important question of:

* 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

[Kirk Wylie]

Yeah, I think it was a north of the river phenomenon when all the cool
kids were up in Shoreditch. Times change, and with the Rabbit team
(courtesy of their new EMC/VMWare/SpringSource hierarchy of benevolent
dictators) down here in lovely, sunny bankside, it might be time for
everybody to get their stab vests on and sojourn down to Silicon
Wobbly Bridge.

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.

[Kirk Wylie]

Well, no, some of us are sucking on the big Venture Capital tit. :-)

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?

[Alvaro Videla]

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

[Alexis Richardson]

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...

[Alexis Richardson]

Right, so: deferring to the various folks coming from abroad for the
Erlang Factory, I propose we return to the POET

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

[Oleg Zhurakousky]

What is the main difference between the two?

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

[Simon MacMullen]

On 04/06/10 16:17, Oleg Zhurakousky wrote:
> What is the main difference between the two?
>
> 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

[Oleg Zhurakousky]

Thanks, 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

[Simon MacMullen]

On 04/06/10 16:54, Oleg Zhurakousky wrote:
> 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

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.

[Oleg Zhurakousky]

Well, 'a' and 'b' are actually different IMHO.

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

[Simon MacMullen]

On 04/06/10 18:03, Oleg Zhurakousky wrote:
> Well, 'a' and 'b' are actually different IMHO.
>
> 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?

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 Zhurakousky]

Well, if the only way for the server to know "the client has processed the message successfully is if it receives an ack", but at the same time server can not wait for an ack forever (in case of client failures), then what is the purpose of an ACK in relation to 'immediate' flag? It seem to be meaningless... right?

Oleg

[Matthew Sackman]

On Sun, Jun 06, 2010 at 10:20:56AM -0700, Oleg Zhurakousky wrote:
> Well, if the only way for the server to know "the client has processed the message successfully is if it receives an ack", but at the same time server can not wait for an ack forever (in case of client failures), then what is the purpose of an ACK in relation to 'immediate' flag? It seem to be meaningless... right?

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