[
https://issues.apache.org/jira/browse/COUCHDB-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650345#comment-13650345
]
Alexander Shorin commented on COUCHDB-1143:
-------------------------------------------
Command line options are been applied once when query server process started
while config options are sends by CouchDB with every reset command (second
optional param). If QS command line changed no already running process be
restarted and you have to kill them all manually to apply changes. Otherwise
whole system enter into some kind of brain split when old and new QS processes
acts different without any possibilities to fix it from CouchDB side (ok, there
is one: make buggy ddoc that will crush every qs process that will try to
handle it - on some iteration all old processes will be killed).
That's this issue about.
> 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
