Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
From: davisp <git@git.apache.org>
To: dev@couchdb.apache.org
Reply-To: dev@couchdb.apache.org
References: <git-pr-1-couchdb-couch@git.apache.org>
In-Reply-To: <git-pr-1-couchdb-couch@git.apache.org>
Subject: [GitHub] couchdb-couch pull request: Add hard limit for OS processes
Content-Type: text/plain
Message-Id: <20140214191542.E27CE92707E@tyr.zones.apache.org>
Date: Fri, 14 Feb 2014 19:15:42 +0000 (UTC)

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.