[rabbitmq-discuss] Erlang client: function_clause error

[Valentino Volonghi]

On Oct 28, 2008, at 4:31 AM, Ben Hood wrote:

> In general, you can help by either contributing code yourself or by
> financing the reprioritization of the roadmap.
>
> Disk overflow or queue paging is on the mid term roadmap as something
> we are going to do, but we still need to gather requirements.
>
> Here are a few examples:
>
> - When do you decide to page things to disk?

I'd say memory high watermark reached or, if reached before, a number
of messages in the queue.

> - Is it done on memory consumption or queue depth?

Both. Depends on which one is reached first, I can see use cases for
both of these triggers.

> - Is this configurable per queue or across the broker?

Across the broker, other AMQP implementation have a 'maximum number
of messages in a queue' as a per broker option.

> - What are sensible defaults so that people who haven't even though
>  about paging don't get affected by overly-agressive defaults?

If a user was not affected before it won't be affected even after  
because
he won't need to overflow to disk anyway. In case the limit hit is the  
number
of messages then simply set it to infinite when no different is  
specified. Then
it will only use memory watermark and this would give them more  
robustness
going from simply crashing the erlang VM because memory is finished to
slowing down because you are now reading from disk.

> - When and how do you swap back in - is this automatic or manual?

When the buffer in the disk is empty then rabbitmq can stop using it,  
I expect
it to deliver messages in order so once the buffer kicks in I'd queue  
stuff on
disk immediately.

> - How do you decide when the low water mark has been reached after
>  having commenced the page-in? Do you resume flow control at this  
> point?

When the disk buffer is empty. And you simply resume working without it.

> - If you do page, are you interested in last image caching?

I'm not sure what this means but looks like an optimization, it's  
probably
interesting to have but caching can come when the system can resist
prolonged consumer downtimes.

Anyway being an optimization in the queue process it should be fairly
isolated in it. I can totally see keeping the current page always in  
memory
(if this is the optimization we are talking about), the big problem is  
keeping
everything in memory.

> - Do you want to apply application level heuristics to selectively  
> purge
>  overflowed queues?

ActiveMQ offers basically 3 different ways to deal with the problem:
kill the queue, drop all new messages, drop old messages.

This can be taken care of in the publish command of rabbitmq.

> - What role do TTLs play in this scenario?

It's not the role of the message broker to kill single messages, it's  
an application
level decision. I can see a configuration option in the queue though  
that together
with the 3 options above can provide a 'kill all the messages older  
than X seconds'.

This can be taken care inside the queue itself when getting the top of  
the queue.

> - Furthermore, we do already have a fast message persister - it's just
>  that it's geared to write as quickly as possible, not read.

And this is a great to me.

> - Ask yourself, if we implement paging, is are we potentially  
> reinventing
>  a wheel that the OS has already invented?

Well, sure. But erlang fails before when it cannot malloc memory.

> - And as always, what do you do when your SAN fills up?

If a 500-600GB disk fills up it means I had at least ~80 times more  
time to
fix the problem somehow, given an average of 8GB of memory in a  
webserver.
So if with 8GB of memory I had 10 hours to fix it, with a disk I have  
30 days to
fix it, and I can even add new disks with a good disk array or  
filesystem to buy
me more time.

> One suggestion to kick things off is to begin a more structured
> analysis of the whole problem on the wiki and start a dedicated
> discussion thread around this. For example, one could start a document
> highlighting the motivation and requirements and let interested
> parties comment on this.

Good, I'm all for this. And I'm starting with this reply.

> Having said that, whilst it may be straight forward to do a hello
> world overflow, the devil is in the detail of all of the moving parts
> and different scenarios that you have to account for whilst maintaing
> the clarity of the code base. And testing it of course.


Yep, this is just right.

-- 
Valentino Volonghi aka Dialtone
Now running MacOS X 10.5
Home Page: http://www.twisted.it
http://www.adroll.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081028/59ef4692/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081028/59ef4692/attachment.pgp