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

Alex Petrov commented on CASSANDRA-14937:
-----------------------------------------

Thank you for the patch, I like the direction and think it will be a great 
addition!

  * {{InvokableInstance}} serves no other purpose than add implementation to 
InvokableInstance methods. We can use default implementations on interface and 
get rid of this class alltogether. 
  * 
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:14937-3.0#diff-3a4f5b9b5507554db09adad8022b0811R35]
 we do not need to have a full package name 
{{org.apache.cassandra.distributed.api.}}
  * it seems that {{IMessage}} doesn't have to be interface with each version 
having it's own implementation 
  * in {{Listen}}, outer loop doesn't look like necessary 
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:14937-3.0#diff-8b99167f6379cc470fcbaf5f640a098eR38],
 also package name can be removed 
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:14937-3.0#diff-8b99167f6379cc470fcbaf5f640a098eR26]
  * {{new Object[][]}} 
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:14937-3.0#diff-3a4f5b9b5507554db09adad8022b0811R70]
 can be constant 
  * VERSION_4 
[here|https://github.com/apache/cassandra/compare/trunk...belliottsmith:14937-3.0#diff-3a4f5b9b5507554db09adad8022b0811R62]
 probably should be CURRENT_VERSION
  * probably this will be documented, but "build" directory is currently 
assumed to be under resources or?
  * maybe for debugging purposes we could list found versions (also, we could 
do it once per test class)
  * if you at 3.0 branch, you can't start 3.11 or 4.0 cluster because of CDC. 
On the more general note. Since configs are generated from "cluster" 
perspective (in {{AbstractCluster#create}}, we do not get to pick a right 
config for the version. 
  * Exceptions on when instance can't be load are currently not very verbose, 
you just get NPE. It'd be great if we could say "couldn't find your version, 
please put it there and there".
  * trunk produces extra blank line after each log line and kind of has a weird 
formatting, looks like something might be double-wrapped:
{code}
INFO  [node3_isolatedExecutor:2] 2019-01-18 16:49:19,848 
SubstituteLogger.java:169 - DEBUG [node3_isolatedExecutor:2] node3 2019-01-18 
16:49:19,845 DatabaseDescriptor.java:307 - Syncing log with a batch window of 
1.0
{code}
  * {{InstanceClassLoader#id}} is now unused
  * {{InstanceClassLoader#sharedPackageNames}} is a predicate, but is named as 
noun, it'd be great to change the name.
  * it looks like right now, to test _current_ version, you have to re-package. 
But this shouldn't be the case, we can just use current version class path 
without wrapping it into jar. This could really improve development cycle, 
especially when you know which version "misbehaves" 
  * it looks like we can not create mixed-version cluster at the moment even 
though nothing prevents it. Maybe it was planned for future? For example, 
create a cluster with 3.0 and 4.0 without upgrades. I see quite a few use-cases 
for that.

> Multi-version In-JVM dtests
> ---------------------------
>
>                 Key: CASSANDRA-14937
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14937
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Test/dtest
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Major
>             Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> In order to support more sophisticated upgrade tests, including complex fuzz 
> tests that can span a sequence of version upgrades, we propose abstracting a 
> cross-version API for the in-jvm dtests.  This will permit starting a node 
> with an arbitrary compatible C* version, stopping the node, and restarting it 
> with another C* version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Reply via email to