[
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.3)
> 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
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
