Source code
package io.netty.testsuite.transport.socket;
import io.netty.bootstrap.Bootstrap;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.Channel;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.IoEventLoopGroup;
import io.netty.channel.nio.NioIoHandler;
import io.netty.testsuite.transport.TestsuitePermutation;
import io.netty.util.NetUtil;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInfo;
import org.junit.jupiter.api.Timeout;
import java.nio.channels.AlreadyConnectedException;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class SocketMultipleConnectTest extends AbstractSocketTest {
@Test
@Timeout(value = 0x7530, unit = TimeUnit.MILLISECONDS)
public void testMultipleConnect(TestInfo testInfo) throws Throwable {
run(testInfo, new Runner<ServerBootstrap, Bootstrap>() {
@Override
public void run(ServerBootstrap serverBootstrap, Bootstrap bootstrap) throws Throwable {
testMultipleConnect(serverBootstrap, bootstrap);
}
});
}
public void testMultipleConnect(ServerBootstrap sb, Bootstrap cb) throws Exception {
Channel sc = null;
Channel cc = null;
try {
sb.childHandler(new ChannelInboundHandlerAdapter());
sc = sb.bind(NetUtil.LOCALHOST, 0x0).syncUninterruptibly().channel();
cb.handler(new ChannelInboundHandlerAdapter());
cc = cb.register().syncUninterruptibly().channel();
cc.connect(sc.localAddress()).syncUninterruptibly();
ChannelFuture connectFuture2 = cc.connect(sc.localAddress()).await();
assertTrue(connectFuture2.cause() instanceof AlreadyConnectedException);
} finally {
if (cc != null) {
cc.close();
}
if (sc != null) {
sc.close();
}
}
}
@Override
protected List<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>> newFactories() {
List<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>> factories
= new ArrayList<TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap>>();
for (TestsuitePermutation.BootstrapComboFactory<ServerBootstrap, Bootstrap> comboFactory
: SocketTestPermutation.INSTANCE.socketWithFastOpen()) {
EventLoopGroup group = comboFactory.newClientInstance().config().group();
if (group instanceof IoEventLoopGroup && ((IoEventLoopGroup) group).isIoType(NioIoHandler.class)) {
factories.add(comboFactory);
}
}
return factories;
}
}
Run 1
The code is generally structured but has readability issues. It uses try-finally properly for resource cleanup, and test setup follows a clear pattern. However, several things reduce clarity: magic numbers like 0x7530 and 0x0 instead of descriptive constants, deeply nested anonymous inner class, and long method chains that obscure flow. The newFactories() method has a complex generic type declaration and filtering condition that's hard to parse quickly. Variable names like 'sb', 'cb', 'sc', 'cc' are too abbreviated for clarity, though they're used consistently. The action granularity is mixed — some lines do too much while others are fine. The import list is long but standard for Netty tests. Overall, it's readable for experienced Netty developers but less approachable for others.
Run 2
The code has a clear structure with proper try/finally resource cleanup, but suffers from several readability issues. Magic numbers (0x7530, 0x0) obscure intent - why use hex for timeout and port? The nested anonymous Runner class adds unnecessary indirection. Method naming is ambiguous: testMultipleConnect is both a test wrapper and implementation method. The newFactories method has deep nesting and complex generic types exceeding 120 characters. Multiple operations are chained on single lines (e.g., bind().syncUninterruptibly().channel()), violating the one-action-per-line principle. Import statements are clustered without grouping. The action granularity forces readers to parse method chains mentally rather than seeing discrete steps. Finally, the dual registration pattern (test method + Runner + implementation) creates three layers of indirection for what is essentially a simple test case, making the reading flow feel disorganized despite the logic being correct.
Run 3
The code has clear structure with a standard test pattern, but several readability issues reduce the score. The test method is reasonably flat and follows a logical setup-action-assert flow. However, the intent is obscured by magic numbers like 0x7530 for timeout and 0x0 for port - developers must mentally decode hex values. The method name 'testMultipleConnect' appears twice with different signatures, which could cause confusion. Generic type declarations are verbose, creating long lines that hurt readability. The nesting in newFactories() adds complexity with nested generics and conditionals. Action granularity is mostly good, though multiple operations chain on single lines (e.g., bind().syncUninterruptibly().channel()). The try-finally block properly handles cleanup but lacks comments explaining why the second connect should fail with AlreadyConnectedException. Import organization is alphabetical, which aids navigation. Overall, functional but would benefit from named constants, shorter generic types, and clearer separation of test phases.
Run 1
Code Structure: Well organized into a test entry point, connection test, and factory-selection override, with explicit cleanup. Nesting: Generally shallow; the anonymous runner and loop condition add manageable complexity. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the purpose, but abbreviated variables (sb, cb, sc, cc), hexadecimal constants, and the unexplained factory filter reduce clarity. Code length: Reasonably concise, though the anonymous runner and repeated generic types add boilerplate. Action granularity: Statements generally perform one logical action per line; fluent calls combine related setup and synchronization steps without excessive density. Reading flow: Setup, first connection, second connection, assertion, and cleanup follow a natural sequence. Long generic declarations and the compound type-check condition slightly interrupt scanning.
Run 2
Code Structure: Methods cleanly separate test execution, connection behavior, and factory filtering. Nesting: Mostly shallow, with manageable anonymous-class, try/finally, and loop/conditional nesting. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the purpose, but abbreviated variables (sb, cb, sc, cc) and hexadecimal literals obscure details. Code length: Reasonably concise, although verbose generic declarations and the anonymous Runner add boilerplate. Action granularity: Statements generally perform one logical action per line; fluent call chains remain understandable. Reading flow: Setup, first connection, repeated connection, assertion, and cleanup follow a natural sequence. Factory filtering is straightforward, though long type signatures and casts interrupt scanning. Import grouping and descriptive variable names could improve readability.
Run 3
Code Structure: Methods logically separate test dispatch, connection behavior, and factory filtering. Nesting: Mostly shallow, with manageable try/finally cleanup, conditional checks, and a loop. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the purpose, but abbreviated variables (sb, cb, sc, cc) and hexadecimal constants obscure details. Code length: Reasonably concise, although the anonymous Runner and repeated generic types add boilerplate. Action granularity: Statements generally perform one logical action per line; fluent call chains remain understandable. Reading flow: Setup, initial connection, repeated connection, assertion, and cleanup follow a natural sequence. Long generic declarations and reliance on inherited test infrastructure slightly interrupt readability.