Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 5 Jan 2012 17:34:47 +0000 (UTC)
From: "Jan Lehnardt (Updated) (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <64367252.10312.1325784887216.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1101606749.6866.1303934523243.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (COUCHDB-1143) Improve query_server_config section
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Lehnardt updated COUCHDB-1143:
----------------------------------

    Fix Version/s:     (was: 1.2)
                   1.3

Bump to 1.3.x.
                
> Improve query_server_config section
> -----------------------------------
>
>                 Key: COUCHDB-1143
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1143
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Infrastructure, JavaScript View Server
>            Reporter: Alexander Shorin
>            Priority: Minor
>              Labels: features
>             Fix For: 1.3
>
>
> Situation:
> CouchDB query_server_config tells us that it holds all query server configuration and at least js query server approves this by State.query_config object.
> However, there couldn't be defined any options except of reduce_size and os_timeout - others are just ignored.
> Idea:
> Allow to pass all options setted within query_server_config section to query server!
> But, because one CouchDB server could have a lot of query servers, that may have different and similar options in same time, placing all of them within query_server_config set is not rational.
> So they could to be splitted to shared and specific ones:
> query_server_config
> ---> python_server_config
> ---> javascript_server_config
> ---> clojure_server_config
> ---> {server_name}_server_config
> Where {server_name} is same as key in query_servers option set. So there could be a some kind standard of query server configuration that could be easily extended or overrides by local query server configuration.
> Reasons why it could be useful:
> - Flexible customization of query server. 
> Better if CouchDB server restart wouldn't be required (that's could be done via reset command). Current solution with command line query server arguments requires of it and that's not good.
> - Each query server could have own configuration. There could be debug/production query server sets for easily analyzing any problems or other things.
> - Higher customization gives access to very very sweet things.
> For what it could be used?
> - Allow GET requests for _update functions without query server code change
> - Control log level and logging sources and destinations
> - Control query server language specific things such as json module, optimizations.
> - If someday maps would work in async mode, there also could be defined how many workers qs must have spawned.
> - Self monitoring for memory consuming and idle time to have suicide with cry in logs
> Usage of this feature is limited only by query server developer fantasy.
> How to implement this?
> I suppose, that for this sections value field should be tracked as json encoded value (not object or list required, just valid value) so this trick should remove type guessing hell, just check if value is correct json one and leave it processing for query server.
> However, while I've wrote this issue text, I've realized some flaws of this feature.
> Reasons why it just wasting of time and should not being implemented:
> - Complex configurations makes relax time lesser.
> - Poorly couchapp portability due to specific server configuration and debuging hell due to invalid of it.
> - Not all query servers would be use it - suddenly, a most part of them have stopped at point of 0.8.0 release.
> - Not all query servers are really needs in them due to various reasons.
> - Not all couchapps would use all this customizations in full power. Only news one and only may be.
> That's all my thoughts(: A little strange to finish issue description on WONTFIX note, but may be I'm wrong about those reasons. Have someone more thoughts about subject?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira