| Author |
Message |
|
| Guest |
 Posted: Tue Jan 05, 2010 8:55 pm |
 |
|
|
Guest
|
Is there a desire to support the R12B releases of Erlang with the new
persister code? It looks like recently ets:update_element snuck in,
which didn't exist until R13. Can this easily be worked around, or
will R13 be a requirement now?
=SUPERVISOR REPORT==== 5-Jan-2010::20:40:43 ===
Supervisor: {local,rabbit_sup}
Context: child_terminated
Reason: {undef,[{ets,update_element,
[238,
<<19,53,189,149,61,162,5,156,139,171,9,249,66,
14,245,26>>,
{3,2}]},
{rabbit_msg_store_ets_index,update_fields,3},
{rabbit_msg_store,handle_cast,2},
{gen_server2,handle_msg,7},
{proc_lib,init_p,5}]}
Offender: [{pid,<0.268.0>},
{name,rabbit_msg_store},
{mfa,
{rabbit_msg_store,start_link,
...
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jan 05, 2010 9:16 pm |
|
|
|
Guest
|
On Jan 5, 2010, at 2:55 PM, tsuraan wrote:
> Is there a desire to support the R12B releases of Erlang with the new
> persister code? It looks like recently ets:update_element snuck in,
> which didn't exist until R13. Can this easily be worked around, or
> will R13 be a requirement now?
>
There was a post to the list about 6 weeks ago talking about how much
better the R13 garbage collector works with the new persister. I am
pretty sure the devs are going to make R13 a requirement for that code
so that it runs and behaves well.
cr
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jan 05, 2010 10:20 pm |
|
|
|
Guest
|
> There was a post to the list about 6 weeks ago talking about how much
> better the R13 garbage collector works with the new persister. I am
> pretty sure the devs are going to make R13 a requirement for that code
> so that it runs and behaves well.
Yeah, I read the discussion (and the commits where a ton of explicit
gc:collect calls were removed). I was hoping R12 would still work,
since I have it on about 1200 machines that I'll otherwise have to
upgrade 
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 12:03 pm |
|
|
|
Guest
|
On Tue, Jan 05, 2010 at 04:20:02PM -0600, tsuraan wrote:
> > There was a post to the list about 6 weeks ago talking about how much
> > better the R13 garbage collector works with the new persister. I am
> > pretty sure the devs are going to make R13 a requirement for that code
> > so that it runs and behaves well.
>
> Yeah, I read the discussion (and the commits where a ton of explicit
> gc:collect calls were removed). I was hoping R12 would still work,
> since I have it on about 1200 machines that I'll otherwise have to
> upgrade
Thanks for that report. I need to check with Matthias on this one.
Personally, ets:update_element is so useful (mainly because it's atomic
which helps massively with concurrent access to ets tables) that I would
argue in favour of requiring R13, and indeed I'm planning on adding more
ets:update_element calls this afternoon!
Having checked the code, the update_element calls in msg_store and
msg_store_gc could be worked around. The update_element in
msg_store_ets_index can't be, but if you use the rabbitmq-toke plugin
then that avoids that.
ets:update_element appeared in R12B2, according to
http://www.erlang.org/download/otp_src_R12B-2.readme . The last time we
had this discussion in the office, I _think_ we maybe settled on saying
that we would support back to Debian stable (currently lenny), which is
R12B3. Given that Debian testing (squeeze) is already on R13B2, and our
release cycle is probably slower than Debian's, I would be surprised if
the new persister is released before the squeeze goes stable! Thus you
may well find that by the time it's released, we require R13.
Matthew
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 6:05 pm |
|
|
|
Guest
|
> I now *have* to ask what you are doing with 1200 machines. Please can
> you say a bit about that? Is RabbitMQ on all of them?
It's not a huge cluster or anything like that; it's around 1200 (I
really don't know the exact number, but I think it's in that
neighborhood) customers that are running the machines we sold them,
and Rabbit's running on all (or at least all up-to-date) of them. We
started out with the database-as-a-message-queue antipattern, but that
worked as well for us as it does for everybody else, so we found a
nice alternative Even with having to work around rabbit's current
out of memory behaviour, it's a ton better than trying to use a
Postgres table as a queue.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 6:41 pm |
|
|
|
Guest
|
> Having checked the code, the update_element calls in msg_store and
> msg_store_gc could be worked around. The update_element in
> msg_store_ets_index can't be, but if you use the rabbitmq-toke plugin
> then that avoids that.
If the update_element makes the code cleaner or makes it work better,
that's probably best. It sounds like upgrading to R13B3 is a really
good idea for the gc behaviour, so I'd imagine I'll have to do the
upgrade either way
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 7:35 pm |
|
|
|
Guest
|
On Wed, Jan 06, 2010 at 12:40:25PM -0600, tsuraan wrote:
> If the update_element makes the code cleaner or makes it work better,
> that's probably best.
Because of its atomic pattern, there are simply things that I can't do
without it.
> It sounds like upgrading to R13B3 is a really
> good idea for the gc behaviour, so I'd imagine I'll have to do the
> upgrade either way
Yup, best bite the bullet sooner rather than later! 
Matthew
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Jan 07, 2010 5:18 pm |
|
|
|
Guest
|
Tsuraan,
Thank-you very much for the info. That's really good to know.
alexis
On Wed, Jan 6, 2010 at 6:04 PM, tsuraan <tsuraan@gmail.com> wrote:
>> I now *have* to ask what you are doing with 1200 machines. |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
