[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16703: --- Fix Version/s: 4.0.1 3.11.11 3.0.25 Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/eadb171d5dfa9de3ecc6dce47515d48771fa98f9 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into cassandra-3.0 at eadb171d5dfa9de3ecc6dce47515d48771fa98f9 and merged into cassandra-3.11, cassandra-4.0 and trunk > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0.1 > > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16703: --- Status: Ready to Commit (was: Review In Progress) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16703: --- Reviewers: Benjamin Lerer, Brandon Williams, Francisco Bento (was: Brandon Williams, Francisco Bento) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Bento da Silva Neto updated CASSANDRA-16703: -- Impacts: (was: None) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16703: - Reviewers: Brandon Williams, Francisco Bento, Brandon Williams (was: Brandon Williams, Francisco Bento) Brandon Williams, Francisco Bento, Brandon Williams (was: Brandon Williams, Francisco Bento) Status: Review In Progress (was: Patch Available) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 50m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16703: - Status: Patch Available (was: Review In Progress) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 40m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ersek updated CASSANDRA-16703: - Status: Review In Progress (was: Changes Suggested) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 40m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ersek updated CASSANDRA-16703: - Attachment: 16703-trunk.txt > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 40m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ersek updated CASSANDRA-16703: - Attachment: (was: 16703-trunk.txt) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16703: - Reviewers: Brandon Williams, Francisco Bento (was: Brandon Williams, Francisco Bento) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 20m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16703: - Status: Changes Suggested (was: Review In Progress) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 20m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16703: - Reviewers: Francisco Bento, Brandon Williams (was: Brandon Williams, Francisco Bento) Francisco Bento, Brandon Williams Status: Review In Progress (was: Patch Available) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 20m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ersek updated CASSANDRA-16703: - Test and Documentation Plan: Started cassandra with invalid custom query handler, verified it fails and dies Started cassandra with valid custom query handler, verified it started up and info log appeared Status: Patch Available (was: Open) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 10m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ersek updated CASSANDRA-16703: - Attachment: 16703-trunk.txt > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Assignee: Zoltan Ersek >Priority: Normal > Attachments: 16703-trunk.txt > > Time Spent: 10m > Remaining Estimate: 0h > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16703: - Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > Exception thrown by custom QueryHandler constructor is ignored > -- > > Key: CASSANDRA-16703 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16703 > Project: Cassandra > Issue Type: Bug > Components: Local/Startup and Shutdown >Reporter: Francisco Bento >Priority: Normal > > When a exception is thrown during the instantiation of the > _cassandra.custom_query_handler_class,_ depending on the exception thrown > cassandra will simply log an info message and proceed with the bootstraping > with the standard _QueryHandler_ as a fallback measure: > [https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104] > The end-user will never know if the custom _QueryHandler_ is actually > registered or not, unless he notices the info message on the logs. > Ideally, the message should be logged as error and JVM should stop as it > cannot proceed according with the user expected configuration. > *Scenario*: > In our scenario, we have a custom _QueryHandler_ that receives specific > configuration, and we throw a _ConfigurationException_ at instantiation time > in case of any invalid config value. It is expected that cassandra stop the > bootstraping instead of skipping the QH. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
