<html><head></head><body bgcolor="#FFFFFF"><div>Hi</div><div><br>On 15 Oct 2013, at 18:58, "PATAR, SAGAR" &lt;<a href="mailto:sp345s@att.com">sp345s@att.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>

<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:Tahoma;
        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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.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]-->


<div class="WordSection1">
<p class="MsoNormal">Is there a way we can define time to live on a message published to a durable exchange ..</p></div></div></blockquote><div><br></div><div>Not really, because exchanges don't hold messages, only queues do.</div><br><blockquote type="cite"><div><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">What happens when a message binding key doesn’t matches any binding .. does it stay in the durable exchange till the time to live is expired ..
</p></div></div></blockquote><div><br></div><div>No. When messages are unroutable, they're discarded (and possibly returned to the sender, depending on how they were published).</div><br><blockquote type="cite"><div><div class="WordSection1"><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Scenario 1:<o:p></o:p></p>
<p class="MsoNormal">Let’s say we have a time to live of 2 hr for a message and its published to a durable exchange with no binding Key match (ex: binding key = NoMatch) … after 1 hr let’s say a &nbsp;client subscribes for messages with bindingKey =”NoMatch” on
 that exchange .. will the message be delivered to the client ??<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p></div></div></blockquote><div><br></div><div>To do this, you might create a catch all binding to a queue on which you've set a 1hr TTL and configure a dead-letter-exchange to republish if necessary.</div><div><br></div><div>When subscribing, consume from both the catch all queue and the queue you're actually interested in. But of course the message will be routed to both queues so you'll see it twice if it matches the 'real' binding.</div><div><br></div><div>You might be able to work around this with some crazy complex topology, but I doubt it. You can de-duplicate based on correlation-id, though of course this puts storage requirements onto your application.</div><div><br></div><div>Personally, I'd try to re-design the system to avoid this scenario, perhaps by handling unroutable messages on the sender instead, or by attaching a housekeeper to the catch all queue that republishes periodically. Bear in mind that if your "client subscribes to messages with a binding key "NoMatch" - I assume this means they create a temporary queue and bind it tot the exchange - then just having the TTL plus setting the dead letter exchange might work, though once a cycle is detected you'll loose the message iirc.</div><br><blockquote type="cite"><div><div class="WordSection1">
<p class="MsoNormal">Scenario 2:<o:p></o:p></p>
<p class="MsoNormal">Let’s say we have a time to live of 2 hr for a message and its published to a durable exchange with a binding key match (ex: binding key = match)&nbsp; and the message will be routed to a queue and is consumed by a client .. After 1 hr If a
 new client subscribes for the messages with bindingKey =”match” by creating a new Queue ..will the new client get the&nbsp; same message
<o:p></o:p></p>
<p class="MsoNormal"><br></p></div></div></blockquote><br><div>That won't work, since once a message is delivered it will be removed from the queue. You could try doing the thing above (with TTL and DLX) an use a fanout exchange to simulate this, but there are probably lots of corner cases that wont work as expected.</div><div><br></div><div>Cheers,</div><div>Tim</div></body></html>