No subject

Regards,

Gavin


On Friday, May 13, 2011 at 8:10 AM, Matthew Sackman wrote: 
> On Fri, May 13, 2011 at 10:58:34AM +0100, Simon MacMullen wrote:
> > Depends how you define "bad idea". In terms of today's
> > implementation you should be fine, as long as you don't expect (for
> > example) to be able to flip the durability field and have that mean
> > something.
> 
> It's a very bad idea. For one thing, Rabbit assumes that the queue
> record is unaltered after the queue has been created. Consequently the
> amqqueue_process process takes a copy of the #amqqueue record and holds
> it in its state. It never updates it. So if you change the copy in
> mnesia, then you subsquently have divergence between the queue process's
> copy, and the mnesia copy. This can lead to suprising results.
> 
> For example if you issue amqqueue:info on a queue then it'll go through
> to the queue and not mnesia. Thus you'll find that results in management
> and in rabbitmqctl now don't match.
> 
> You then have things like the property that queue redeclaration should
> fail if arguments do not match (semantically) the original declaration.
> But this only goes as far as mnesia. Consequently, you will have the
> queue, if you interrogate it, claiming its arguments are one thing, but
> if you try to redeclare the queue with those arguments, you can find
> it'll fail because the mnesia copy is different.
> 
> Finally, you'll have the fact that if the broker is restarted, you'll
> have the queues recovered with their arguments taken from mnesia. So
> suddenly on startup, you'll have queues being restarted with different
> arguments from that which they were last running with.
> 
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> 

--4dcd5899_79838cb2_19f6
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>
            <div>
                <span>Matthew,</span></div><div><span><br></span></div><d=
iv><span>=46rom your perspective is there any way to do this that's not a=
 bad idea while not impacting production queue use=3F Your points are val=
id, however since they're arguments and Rabbit doesn't care about or use =
arguments, I wonder how impacting it can be=3F</span></div><div><br></div=
><div>Regards,</div><div><br></div><div>Gavin</div><div><span><br></span>=
</div><div><span><br></span></div><div>
                <span></span>
               =20
                <=21-- <p style=3D=22color: =23a0a0a0;=22>On =46riday, Ma=
y 13, 2011 at 8:10 AM, Matthew Sackman wrote:</p> -->
                <p style=3D=22color: =23a0a0a0;=22>On =46riday, May 13, 2=
011 at 8:10 AM, Matthew Sackman wrote:</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div>On =46ri, May 13, 2011 at 10:58:34AM =
+0100, Simon MacMullen wrote:<br><blockquote type=3D=22cite=22><div>Depen=
ds how you define =22bad idea=22. In terms of today's<br>implementation y=
ou should be fine, as long as you don't expect (for<br>example) to be abl=
e to flip the durability field and have that mean<br>something.<br></div>=
</blockquote><br>It's a very bad idea. =46or one thing, Rabbit assumes th=
at the queue<br>record is unaltered after the queue has been created. Con=
sequently the<br>amqqueue=5Fprocess process takes a copy of the =23amqque=
ue record and holds<br>it in its state. It never updates it. So if you ch=
ange the copy in<br>mnesia, then you subsquently have divergence between =
the queue process's<br>copy, and the mnesia copy. This can lead to supris=
ing results.<br><br>=46or example if you issue amqqueue:info on a queue t=
hen it'll go through<br>to the queue and not mnesia. Thus you'll find tha=
t results in management<br>and in rabbitmqctl now don't match.<br><br>You=
 then have things like the property that queue redeclaration should<br>fa=
il if arguments do not match (semantically) the original declaration.<br>=
But this only goes as far as mnesia. Consequently, you will have the<br>q=
ueue, if you interrogate it, claiming its arguments are one thing, but<br=
>if you try to redeclare the queue with those arguments, you can find<br>=
it'll fail because the mnesia copy is different.<br><br>=46inally, you'll=
 have the fact that if the broker is restarted, you'll<br>have the queues=
 recovered with their arguments taken from mnesia. So<br>suddenly on star=
tup, you'll have queues being restarted with different<br>arguments from =
that which they were last running with.<br><br>Matthew<br>=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>rabbitmq-discuss m=
ailing list<br><a href=3D=22mailto:rabbitmq-discuss=40lists.rabbitmq.com=22=
>rabbitmq-discuss=40lists.rabbitmq.com</a><br><a href=3D=22https://lists.=
rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss=22>https://lists.r=
abbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br></div></div>=
</span>
               =20
               =20
               =20
               =20
                </blockquote>
               =20
                <div>
                    <br>
                </div>
            </div>
        </div>
--4dcd5899_79838cb2_19f6--