couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From davisp <...@git.apache.org>
Subject [GitHub] couchdb-couch pull request: Add hard limit for OS processes
Date Fri, 14 Feb 2014 19:15:42 GMT
Github user davisp commented on the pull request:

    https://github.com/apache/couchdb-couch/pull/1#issuecomment-35115035
  
    There's a problem with the waiting queue not being per-language here. This would block
some clients of idle languages if one of the languages happens to reach its hard limit.
    
    There are basically three approaches I see to fixing this:
    
    1. Remove the per-language limits and just have a global limit. The down fall here would
be fore people that have a mix of both native processes and OS processes where the weight
of each is significantly different (although this is tempered by the fact that there's no
way to configure the limits independently).
    
    2. Turn the queue into something keyed by language as well. A dict of queues I think would
not be good here. I think we'd have to figure out either something ets based or add in a process
for each queue. This would probably be the least disruptive approach.
    
    3. Change the supervision tree so that the logic is all independent. I would rename the
current couch_proc_manager to something like couch_proc_lang_manager, and then a new couch_proc_manager
would just forward requests to the proc_lang_manager for the particular language. There's
an extra message pass involved here as well as more overhead in managing the proper couch_proc_lang_managers
in response to the config. (ie, stopping and starting them as the config changes etc). And
in general it'd be a lot more code churn.
    
    I'm torn between 1 and 3. 1 would have the behavior change but I'm having a hard time
convincing myself that's important. 3 would be best for maintaining the current behavior but
with a higher development cost. I can't think of a good solution for 2 that doesn't make me
cringe for one reason or another.        



Mime
View raw message