[
https://issues.apache.org/jira/browse/CASSANDRA-20287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019909#comment-18019909
]
Sam Tunnicliffe commented on CASSANDRA-20287:
---------------------------------------------
Thanks [~maxwellguo] , the patch looks good to me.
I do have one tiny optional suggestion; perhaps we could add a
{{ClassNotFoundException}} clause to the catch in
{{TriggerExecutor::executeInternal}} so we can return a more specific error to
the client when a node which is missing a configured trigger. At the moment the
error message is super generic:
{code:java}
<Error from server: code=0000 [Server error]
message="java.lang.RuntimeException: Exception while executing trigger on table
with ID: tid:9"> {code}
> Execution of CreateTriggerStatement should not rely on external state
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-20287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20287
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
> Reporter: Sam Tunnicliffe
> Assignee: guo Maxwell
> Priority: Normal
> Fix For: 5.x
>
>
> In its current form, {{CreateTriggerStatement}} attempts to load the trigger
> class when the schema transformation is being applied. This is problematic as
> it means the metadata transformation depends on external state and if the
> class cannot be loaded it throws an {{{}InvalidRequestException{}}}. Once the
> log entry with the enclosing {{AlterSchema}} has been committed to the global
> metadata log, it must be applicable by all instances or they will be blocked
> from applying any further metadata transformations.
> The validation of the class loading could be done prior to submission in
> {{{}AlterSchemaStatement::execute{}}}, which would verify the presence of the
> trigger class on the coordinator. Of course, validation passing on the
> coordinator doesn't guarantee that all instances have the necessary classes
> installed on the classpath so we also need to allow the addition of the
> trigger to {{TableMetadata}} even if the trigger class cannot be loaded.
> Equally, the trigger class may become un-loadable at some point after
> creation, which currently causes log replay to fail.
> There are a couple of options for dealing with an unloadable trigger
> implementation, in addition to clearly logging and reporting an appropriate
> metric. When a table being mutated by a client request has a trigger
> configured but not initialised, we could proceed but attach client warnings
> to the response. Alternatively, we could straight up reject writes on the
> table in question. This behaviour could be made configurable, but it may not
> be worth it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
