<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We’re having a weird issue with our fed vHost in Rabbit 3.2.0. We’ve got three fed queues, topic, fromfed and tofed. You can publish to tofed and topic, and you can subscribe to topic and fromfed – so, either a direct pattern or a triangle,
depending on the route you use. However, we’re having an issue where after a couple months of being up, tofed stops publishing. You can set up a temp queue with the same routing key, and it will work as long as you keep the temp queue up, but as soon as
you remove the temp queue, tofed dies with it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">From our dev team:<o:p></o:p></p>
<div style="mso-element:para-border-div;border-top:solid windowtext 1.0pt;border-left:none;border-bottom:solid windowtext 1.0pt;border-right:none;padding:1.0pt 0in 1.0pt 0in">
<p class="MsoNormal" style="border:none;padding:0in">The federation appears to be set up correctly with the needed bindings, as do the queues. In order to get messages to go through, we had to make a debug/temp queue on the
<span style="color:#1F497D">gemini.</span>test vhost and bind that queue identically to the one bound to the Gemini vhost (they both get bound to e.fed.topic, rk.i.gemini.indexdocs). The temp queue gets two copies of the message because it is on the same vhost,
and the index queue gets the message and continues processing. If we take the binding back off of the temp queue the index queue stops receiving messages.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Any ideas what might be causing this? Any logs or test I can run to narrow the scope of the field?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Kale<span lang="EN" style="font-size:8.5pt;font-family:"Verdana","sans-serif";color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p>This communication contains information that is confidential,<br>
proprietary in nature, and may also be attorney-client privileged<br>
and/or work product privileged. It is for the exclusive use of the<br>
intended recipient(s). If you are not the intended recipient(s) or<br>
the person responsible for delivering it to the intended<br>
recipient(s), please note that any form of dissemination,<br>
distribution or copying of this communication is strictly<br>
prohibited and may be unlawful. If you have received this<br>
communication in error, please immediately notify the sender by replying<br>
to this message and delete this email immediately. Thank you for your cooperation. </p>
<p>Please be advised that neither Altegrity, its affiliates, its employees<br>
or agents accept liability for any errors, omissions or damages<br>
caused by delays of receipt or by any virus infection in this<br>
message or its attachments, or which may otherwise arise as a<br>
result of this e-mail transmission.</p></body>
</html>