No subject
Thu Mar 14 15:04:54 GMT 2013
"local" one, and there are a lot of examples in internet doing "just use
/temp-queue/ for reply".
But relying on replicating autogenerated queues is probably a bad practice
and one that could generate hard to debug problems for application
developer, or in best case just add unnecesary overhead by replicating
queues that don't need to be replicated at all.
>
> I'm trying to fix mcollective over federated servers, the original code
>> used very simple method of sending request to exchange with 'reply-to'
>> header containing name of autogenerated queue, and server then sent
>> reply to that address. Obviously that didnt work over federation
>>
>
> Interesting. I hadn't really thought people would do RPC over federation
> but I think your plan should work.
>
It is mainly because we tried ActiveMQ clustering, and while clustering
worked fine over WAN, we couldn't make ActiveMQ work more than few days
without it going OOM and dying, and even buitin watchdog didnt help much
>
> My first try was just replacing reply queue with direct exchange that
>> client subscribed to to get replies and it worked partially, over
>> federation when client did simple
>> "subscribe(reply_exchange);**publish(request_exchange), but sometimes
>> messages were "lost" probably because server sent reply too fast (before
>> federation managed to subscribe to remote exchange.
>>
>
> Yeah, I think that analysis is right.
>
Is there any way to query exchange about what queues are subscribed to it
over STOMP? I'd like to fix it by simply making server wait for client
subscription to exchange before sending reply.
Cheers,
Mariusz
--20cf30780db0a71bd104e75eb128
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2013/9/27 Simon MacMullen <span dir=3D"ltr"><<a href=3D"mailto:simon at rab=
bitmq.com" target=3D"_blank">simon at rabbitmq.com</a>></span><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
On 27/09/2013 2:16PM, Mariusz Gronczewski wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
I've tested it for a bit and have another question: Is federating<br>
autogenerated (amq.*) queues planned (on current nightly trying to<br>
federate those returns "queue name contains reserved prefix amq")=
or it<br>
is something that should not be used at all ?<br>
</blockquote>
<br>
Hmm. That's kinda problematic - you shouldn't be able to declare yo=
ur own named queue in the server-generated namespace. But the downstream fe=
derated queue is just another AMQP client from the perspective of the upstr=
eam, so it can't violate that requirement.<br>
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Not sure if that's the right thing to do, but that's how it is now.=
Hmm.<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Of course, you could have your client generate a reply queue name based on =
a UUID or something, that would get round the problem.=C2=A0<br></blockquot=
e><div><br>From the point of the client federated queue should work exactly=
like=20
"local" one, and there are a lot of examples in internet doing &q=
uot;just use
/temp-queue/ for reply". <br>But relying on replicating autogenerated=
=20
queues is probably a bad practice and one that could generate hard to=20
debug problems for application developer, or in best case just add unnecesa=
ry overhead by replicating queues that don't need to be replicated at a=
ll.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
I'm trying to fix mcollective over federated servers, the original code=
<br>
used very simple method of sending request to exchange with 'reply-to&#=
39;<br>
header containing name of autogenerated queue, and server then sent<br>
reply to that address. Obviously that didnt work over federation<br>
</blockquote>
<br>
Interesting. I hadn't really thought people would do RPC over federatio=
n but I think your plan should work.<br></blockquote><div>It is mainly beca=
use we tried ActiveMQ clustering, and while clustering worked fine over WAN=
, we couldn't make ActiveMQ work more than few days without it going OO=
M and dying, and even buitin watchdog didnt help much<br>
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
My first try was just replacing reply queue with direct exchange that<br>
client subscribed to to get replies and it worked partially, over<br>
federation when client did simple<br>
"subscribe(reply_exchange);<u></u>publish(request_exchange), but somet=
imes<br>
messages were "lost" probably because server sent reply too fast =
(before<br>
federation managed to subscribe to remote exchange.<br>
</blockquote>
<br>
Yeah, I think that analysis is right.<span class=3D""><font color=3D"#88888=
8"><br></font></span></blockquote><div>Is there any way to query exchange a=
bout what queues are subscribed to it over STOMP? I'd like to fix it by=
simply making server wait for client subscription to exchange before sendi=
ng reply.<br>
</div></div><br>Cheers,<br></div><div class=3D"gmail_extra">Mariusz<br>
</div></div>
--20cf30780db0a71bd104e75eb128--
More information about the rabbitmq-discuss
mailing list