[
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: [email protected]
For additional commands, e-mail: [email protected]
