You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Alexander Shorin (JIRA)" <ji...@apache.org> on 2011/04/27 22:02:03 UTC
[jira] [Created] (COUCHDB-1143) Improve query_server_config section
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
Fix For: 1.2
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1143) Improve query_server_config section
Posted by "Jan Lehnardt (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (COUCHDB-1143) Improve query_server_config
section
Posted by "Alexander Shorin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025999#comment-13025999 ]
Alexander Shorin commented on COUCHDB-1143:
-------------------------------------------
Yes, command lines arguments is all that they have now, but:
1. Any changes in them requires CouchDB server restart, right?
2. If there are a lot of options, this would be a little hard to orient in them
3. Name of section query_server_config in this case creates misunderstood of it's functionality: not to configure query server but to set up few builtin options, nothing more.
4. With own qs config section there could be defined all available options explicitly in their default state without needing to look at query server command line help any time when you have to change something.
> 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.2
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1143) Improve query_server_config
section
Posted by "Randall Leeds (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025992#comment-13025992 ]
Randall Leeds commented on COUCHDB-1143:
----------------------------------------
I see why this sounds interesting, but the query servers list has command lines to launch query servers. Couldn't a query server developer just take command line arguments to their query server program?
> 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.2
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira