Richard,<div>The original memcache architecture docs would say something like, don't expect the data to be available when you query it. In other words, you have to assume that the memcache daemon is going to die painfully and get restarted without any data in it (or maybe won't get restarted).</div>
<div><br></div><div>most (cold cache) memcache implementations usually do a cache check, then a db check (followed by populating the cache). This methodology insures that if the cache disappears, you can still get the data out of your database.</div>
<div><br></div><div>Now I haven't followed the memcache development, but the BDB backed memcache store Shelby has mentioned sounds really cool. But still, what if memcache disappears and does not come back.</div><div>
<br></div><div>Depending on your specific implementation, like call path limiting across platforms, these limitations may be acceptable. I think I personally would find it acceptable to perform call path limiting this way since the only time call paths would get out of whack would be during a failure and presumably the failure wouldn't last longer than 2xACD</div>
<div><br></div><div>That's my $0.02 :)</div><div><br></div><div>If you try this out.. tell us about it.. I'm sure there will be all sorts of interesting uses for memcaching. When I get some free time, I'm going to do full LCR with it. :)</div>
<div><br></div><div>-Brett</div><div><br><div class="gmail_quote">On Wed, Jul 15, 2009 at 3:05 PM, Richard Revels <span dir="ltr"><<a href="mailto:rrevels@bandwidth.com">rrevels@bandwidth.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">I'm thinking of the case where I have multiple proxies that an account can send to and I want to do concurrency counts across them. Doesn't need to be a reliable data store. Just need to be able to update a value here and be able to read it there.<div>
<br></div><div>This module puts ya'll real close to the top of my "pretty cool people" list. Thank you.</div><div><br></div><div><font color="#888888"><br><div> <span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><div><div>Richard Revels</div><div><span style="font-size:medium"><br>
</span></div></div></div></div></div></div></div></div></div></div></span></div></span></div></font><div><div></div><div class="h5"><div><div>On Jul 15, 2009, at 2:01 PM, Brett Nemeroff wrote:</div><br><blockquote type="cite">
I think it's worth re-iterating that memcache is NOT meant to be a reliable data store and you should essentially build your applications assuming the data will NOT be available. Doing some reading on memcache is very worthwhile for proper use of this fantastic capability. The use of OpenSIPs using memcache doesn't really change any of the underlying design principals.<div>
<br></div><div><br><br><div class="gmail_quote">On Wed, Jul 15, 2009 at 12:14 PM, andrei dragus <span dir="ltr"><<a href="mailto:andreidragus@yahoo.com" target="_blank">andreidragus@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> <br> <br> Hi, Richard.<br> <br> Yes.<br> <br> As long as the server (ip and port) is the same, keys are<br> visible from all opensips distribution accessing that<br>
cache.<br> <br> Careful! In some cases this may be unwanted behavior.<br> <br> Also if you use a group of servers you don't have complete<br> control over which keys go on which servers, but if you use<br> the same groups on all opensips servers it is guaranteed<br>
that they are distributed in the same way, so again they are<br> visible from all servers.<br> <br> Andrei.<br> <br> --- On Wed, 7/15/09, Richard Revels <<a href="mailto:rrevels@bandwidth.com" target="_blank">rrevels@bandwidth.com</a>><br>
<div> wrote:<br> <br> <br> > Andrei,<br> ><br> > I'll read the documentation shortly but I wonder if<br> you<br> > could give me <br> > a quick booster here. Does this module allow for<br> two<br>
> or more opensips <br> > proxies to access the same memory cached data on the<br> > distributed cache?<br> ><br> > Richard Revels<br> ><br> ><br> <br> <br> <br> <br> <br> </div><div><div></div>
<div>_______________________________________________<br> Users mailing list<br> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div> _______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>