[
https://issues.apache.org/jira/browse/CASSANDRA-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373362#comment-17373362
]
Zoltan Ersek edited comment on CASSANDRA-16703 at 7/2/21, 9:04 AM:
-------------------------------------------------------------------
Let me know if a patch over 3.0 is needed, I'm not familiar with the process of
merging it to different versions, do we create a new ticket for all versions or
should this cover all of them?
was (Author: zoltanersek):
Let me know if a patch over 3.0 is needed, I'm not familiar with the process of
merging it to different versions, do we create a new ticket for all version or
should this cover all of them?
> 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
