[jira] [Comment Edited] (CASSANDRA-18781) Add the ability to disable bulk load on server end and add metrics for bulk load used

["Stefan Miklosovic (Jira)" <ji...@apache.org>]

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

Stefan Miklosovic edited comment on CASSANDRA-18781 at 8/30/23 7:24 AM:
------------------------------------------------------------------------

[~curlylrt] I took a look at your PR.

Except the comments I put on the PR, I think that this should be added too (1). The reasoning behind that is that if you throw RuntimeException from "deriveSession", it will be caught in catch block of "run" method of StreamDeserializingTask. But if the exception is not an instance of StreamReceiveException, it will never call ((StreamReceiveException)t).session.onError(t.getCause());

onError method, among other things, is doing this:
{code:java}
        if (channel.connected())
        {
            state(State.FAILED); // make sure subsequent error handling sees the session in a final state 
            channel.sendControlMessage(new SessionFailedMessage()).awaitUninterruptibly();
        }
{code}
So it will never send a control message back that the session has failed.

I have also split the tests. Currently, "streamingChannel" is created as part of setup() method (before every test), but is not it true that the channel is closed in "finally" block of run method? So the next test is acting on a closed channel?

 

(1) [https://github.com/instaclustr/cassandra/commit/d4a2a7b0dd040b1671bbd7c50eab5dbfbdc70106]


was (Author: smiklosovic):
[~curlylrt] I took a look at your PR.

Except the comments I put on the PR, I think that this should be added too (1). The reasoning behind that is that if you throw RuntimeException from "deriveSession", it will be caught in catch block of "run" method of StreamDeserializingTask. But if the exception is not an instance of  StreamReceiveException, it will never call ((StreamReceiveException)t).session.onError(t.getCause());

onError method, among other things, is doing this:

{code}
        if (channel.connected())
        {
            state(State.FAILED); // make sure subsequent error handling sees the session in a final state 
            channel.sendControlMessage(new SessionFailedMessage()).awaitUninterruptibly();
        }
{code}

So it will never send a control message back that the session has failed.

(1) https://github.com/instaclustr/cassandra/commit/d4a2a7b0dd040b1671bbd7c50eab5dbfbdc70106

> Add the ability to disable bulk load on server end and add metrics for bulk load used
> -------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-18781
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18781
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tool/bulk load
>            Reporter: Runtian Liu
>            Assignee: Runtian Liu
>            Priority: Normal
>             Fix For: 5.x
>
>
> Currently, Cassandra database users can use sstableloader to bulk load data into Cassandra. However, for a Cassandra operator, there is no way to forcibly block this behavior. Additionally, there is no metric indicating whether the bulk load is being used on the server side. If a client is using sstableloader, they will also need to upgrade the sstableloader code to the new major version. This lack of control and visibility can become a blocker during a major version upgrade.
>  
> 1. Can we add a config to disable bulk load feature? Or it falls into https://issues.apache.org/jira/browse/CASSANDRA-8303
> 2. Can we add metrics for bulk load used on server end?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org