Ok, it was a bit more work than expected, but I have a first cut at mod_limit using memcache checked in. Test if you can. I've not put docs on the wiki 'cause some of the implementation / setup details are going to change with regards to mod_memcache. Oh, and mod_limit's api may be changing to make it more pluggable.
Basically, Setup mod_memcache (on wiki) It uses the same user facing api as limit_hash and friends except it is limit_memcache and limit_memcache_usage. so follow mod_limit's docs with suitable substitutions. On Thu, Aug 27, 2009 at 9:42 AM, Rupa Schomaker<r...@rupa.com> wrote: > limit and memcache haven't been introduced to each other yet -- it is > on my (semi-long) list of things to do. > > If you want it you can: > > 1) do it yourself and submit the patches > 2) open a jira and hope someone does it > 3) open a jira + bounty and someone will probably do it > > It will get done eventually, just hasn't been a itch for ME to scratch yet. > > > To do it: > > 1) I need to make it possible to call inc/dec methods of mod_memcache > to support an expiration time. > > 2) mod_limit.c - use the hash limit as a guide > > Initial pitfalls: > > hash limits concurrent access/modification of the hash and by > implication limit_hash_item_t (hash data) by using a mutex. We can't > mutex across FS instances. > > So perhaps split up limit_has_item_t and spread it across multiple > keys. So instead of one key marked as realm_id, we could have > realm_id_total_usage realm_id_rate_usage and realm_id_last_check. > > This does mean that rate_usage and total_usage can inc/dec independent > of each other, but I think the logic will still be "ok" *IF* we > remember to decrement earlier incremented items in the event a later > item is failed. (so, say we increment rate but fail on total we need > to remember to decrement rate so that we have no net effect on the > counters) > > Alternatively, we could use CAS support and pull the limit_hash_item_t > item from memcache, twiddle it and then try to put it back only if the > check info is the same (no one else has changed the entry). If the > entry has changed, pull the new version, do the limit logic, and try > again. Loop that a few times until you succeed or give up. Problem > is that CAS needs to be explicitly turned on in memcache (some distros > compile with it off), is relatively new in memcache (hint: may have > issues) and has some performance/memory downsides though by how much > I'm not sure. > > Thoughts? > > On Thu, Aug 27, 2009 at 8:49 AM, Woody Dickson<woodydick...@gmail.com> wrote: >> Hello, >> >> I read something that talks about using memcache for mod_limit before. Is >> it something that is available now? >> >> If I have multiple instances of freeswitch that need to share the same limit >> status, it there any existing solution? >> >> If no existing solution is available, what is the best way to go about >> modifying mod_limit to accomplish limiting for multiple freeswitch servers >> together? >> >> Thanks, >> Woody >> _______________________________________________ >> FreeSWITCH-users mailing list >> FreeSWITCH-users@lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> >> > > > > -- > -Rupa > -- -Rupa _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org