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<rupa@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<woodydickson@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