I think the Native dependencies were disabled for in-jvm Netty because they prevented the in-jvm dtest InstanceClassLoaders from being garbage collected and were a source of out-of-metaspace exceptions. I'll echo Alex's comment that you will also need to investigate in-jvm upgrade tests. I'm not sure if it's possible to load two different versions of native libraries concurrently.
Perhaps the netty code has changed and we can re-enable, or perhaps you can determine what was not being released by the native code -- that would be much better and as Alex says more reflective of the common environment. To check if it is now safe, you can use the ResourceLeakTest - you may have to comment out a few @Ignores - the previous bar was for the looperGossiperNetwork test to complete 100 loops. Jon. On Wed, Sep 6, 2023 at 9:32 AM Alex Petrov <al...@coffeenco.de> wrote: > I think most of the time people actually use netty _with_ native. This > might have been introduced when we were tried to make shaded in-JVM dtest > jars. If all tests are passing, and we actually do have a confirmtion that > native Netty is being used, I would say +1 to remove `noNative`. > > Just to make sure though, did you have a chance to see if the upgrade > tests also work fine? > > On Thu, Aug 31, 2023, at 1:20 PM, Miklosovic, Stefan wrote: > > Hi list, > > Currently, we are skipping the usage of native libraries in Netty as part > of testing here (1). > > In 5.0 branch, we upgraded Netty to 4.1.96 and we brought all native > dependencies to the class path so they are there in runtime (x86, arm, mac). > > I conducted few CI tests for 5.0+ and not having > "io.netty.transport.noNative" set to "true" introduces no errors. I think > we were just too motivated here to skip stuff left and right. Having this > property enabled seems to have no functional effect. Also, one negative > side-effect of having this property enabled is that it logs exceptions when > running in-jvm-dtests e.g. in IDEA and it pollutes the logs unnecessarily > and it is just a visual clutter to deal with every time. To silence this, I > set (2) so it skips the logic in (3) completely hence no un-necessary > logging will occure. > > My question is whether we should not remove (4) in 5.0, that means that > tests will use native libraries too. That also means that we are running > tests closer to a production environment. I just do not see any reason why > we should skip this when all tests are just passing with it too with > additional benefit of not seeing an exception logged every time when > testing it locally. > > Thanks > > (1) > https://github.com/apache/cassandra-in-jvm-dtest-api/blob/trunk/src/main/java/org/apache/cassandra/distributed/api/ICluster.java#L95-L102 > (2) > https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java#L196 > (3) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/NativeTransportService.java#L163 > (4) > https://github.com/apache/cassandra-in-jvm-dtest-api/blob/trunk/src/main/java/org/apache/cassandra/distributed/api/ICluster.java#L101 > > >
