couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samuel Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1143) Improve query_server_config section
Date Fri, 03 May 2013 13:12:16 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648388#comment-13648388
] 

Samuel Williams commented on COUCHDB-1143:
------------------------------------------

To what extent should the configuration file alter the run-time behaviour of the query server?
Shouldn't this state be contained within the design document as much as is possible?

If significant per-server configuration is required for a specific application, to what end
is this going to be beneficial/problematic? Ideally, you'd be able to deploy a design document
to any CouchDB server and have it work correctly without needing to restart or otherwise tweak
the configuration of the server.
                
> 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

Mime
View raw message