This sounds like a bug to me, but would be good to get feedback from others who have touched Streaming…
Repair will fail if membership notifies that a participate node was removed, so I think it makes sense for Streaming to also follow this behavior. > On Dec 14, 2022, at 1:22 PM, Natnael Adere <natnael_ad...@apple.com> wrote: > > To give more context, StreamSession is not listening to Gossip for membership > changes. Although it implements an interface for listening to membership > changes, we do not register with Gossip and, therefore, never get these > changes. This results in the IEndpointStateChangeSubscriber interface being > dead code. My question is wether or not this is a bug to be fixed or code to > delete. Currently, streaming does not fail on membership changes because of > this problem. If Gossip says that a node was removed or restarted, should we > fail the stream or not? > > Thanks, > Natnael >> On Dec 14, 2022, at 1:39 PM, Natnael Adere <natnael_ad...@apple.com >> <mailto:natnael_ad...@apple.com>> wrote: >> >> Hello, >> >> I am working on CASSANDRA-17199 >> <https://issues.apache.org/jira/browse/CASSANDRA-17199> and testing for this >> ticket has uncovered some issues with streaming. When creating a >> StreamSession we have an intent for to listen but that never happens. My >> concern is wether or not we should we listen and make sure the interface it >> implements is not dead code or delete the interface and all of its methods. >> Our style guide requires no dead code so this might be intentional, but when >> testing we see that StreamSession not listening. If it is intentional then I >> suppose we make sure that we are listening. Any opinions on what to do in >> this scenario? >> >> >> (PROBLEM) The project compiles in both scenarios: >> public class StreamSession implements IEndpointStateChangeSubscriber >> >> public class StreamSession //implements IEndpointStateChangeSubscriber >> >> >> Thanks, >> >> Natnael >
