[OpenSIPS-Users] Fw: Re: [NEW]memcached implementation for memory caching

[Brett Nemeroff]

Richard,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).

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.

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.

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

That's my $0.02 :)

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. :)

-Brett

On Wed, Jul 15, 2009 at 3:05 PM, Richard Revels <rrevels at bandwidth.com>wrote:

> 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.
> This module puts ya'll real close to the top of my "pretty cool people"
> list.  Thank you.
>
>
>  Richard Revels
>
> On Jul 15, 2009, at 2:01 PM, Brett Nemeroff wrote:
>
> 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.
>
>
> On Wed, Jul 15, 2009 at 12:14 PM, andrei dragus <andreidragus at yahoo.com>wrote:
>
>>
>>
>>
>>  Hi, Richard.
>>
>>  Yes.
>>
>>  As long as the server (ip and port) is the same, keys are
>>  visible from all opensips distribution accessing that
>>  cache.
>>
>>  Careful! In some cases this may be unwanted behavior.
>>
>>  Also if you use a group of servers you don't have complete
>>  control over which keys go on which servers, but if you use
>>  the same groups on all opensips servers it is guaranteed
>>  that they are distributed in the same way, so again they are
>>  visible from all servers.
>>
>>  Andrei.
>>
>>  --- On Wed, 7/15/09, Richard Revels <rrevels at bandwidth.com>
>>  wrote:
>>
>>
>>  > Andrei,
>>  >
>>  > I'll read the documentation shortly but I wonder if
>>  you
>>  > could give me
>>  > a quick booster here.  Does this module allow for
>>  two
>>  > or more opensips
>>  > proxies to access the same memory cached data on the
>>  > distributed cache?
>>  >
>>  > Richard Revels
>>  >
>>  >
>>
>>
>>
>>
>>
>>  _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090715/bc104b89/attachment.htm