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 = 30000, 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());
final int a = 1;
final int b = -1;
sc = sb.bind(NetUtil.LOCALHOST, (a + b)).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 demonstrates clear structure with logical separation of concerns, appropriate try-finally resource cleanup, and flat nesting. Variable names like 'sb', 'cb', 'sc', 'cc' are concise but slightly cryptic, though context makes them understandable. The intent of testing multiple connect attempts is clear. The odd use of '(a + b)' for port calculation (which equals 0) appears unnecessarily convoluted and reduces readability. The factory filtering logic uses long generic type declarations that create verbose lines. Overall, the code follows good practices: one action per line, natural reading flow, and proper exception handling. Minor improvements could include better variable naming and simplifying the port calculation.
Run 2
The code has a clear overall structure with test setup and teardown, but readability is reduced by several factors. The lambda wrapper in testMultipleConnect(TestInfo) adds indirection. Magic numbers a=1 and b=-1 obscure the intent of binding to port 0. The variable names 'sb', 'cb', 'sc', 'cc' are terse and not self-documenting. The method testMultipleConnect contains multiple actions per line in some cases and mixes connection logic with assertions. The newFactories method has long generic type declarations and a condition that is difficult to parse quickly. However, nesting is shallow, exception handling is clean with try/finally, and the test flow is logically organized.
Run 3
The code is generally readable with a clear structure: test method, business logic, and factory method are separated. The main test method has a reasonable linear flow with proper resource cleanup in a finally block. However, several issues reduce readability: the variables 'a' and 'b' are unnecessary abstractions (bind address calculation is obscured); the nested anonymous Runner class adds boilerplate that could be simplified; the magic numbers and cryptic variable names (sb, cb, sc, cc) require mental mapping; the 'newFactories' method contains deep nesting with generics and a conditional check that could be extracted. The intent of testing multiple connect attempts is clear, and each major action is on its own line, but the overall code could benefit from better naming and reduced abstraction overhead.
Run 1
Code Structure: Methods logically separate test execution, connection checks, and factory filtering, with cleanup in finally. Nesting: Mostly shallow, though the anonymous runner and loop conditional add some indentation. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the purpose; abbreviated variables (sb, cb, sc, cc) and the unnecessary a + b calculation obscure details. Code length: Reasonably concise, but anonymous-class boilerplate and repeated generic types add verbosity. Action granularity: Statements generally perform one logical action per line, although chained asynchronous calls combine several operations. Reading flow: Setup, connection, assertion, and cleanup follow a natural sequence; dense imports, long generic declarations, and the distracting port calculation slightly interrupt readability.
Run 2
Code Structure: Methods cleanly separate test execution, connection verification, and factory selection; cleanup is organized in finally. Nesting: Mostly shallow, with modest nesting from the anonymous runner, cleanup checks, and factory filtering. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the expected behavior, but abbreviations such as sb, cb, sc, and cc reduce clarity. Computing port zero through a + b unnecessarily obscures intent. Code length: Reasonably compact, though the anonymous runner and repeated generic types add verbosity. Action granularity: Most lines express one logical action; fluent chains combine related operations coherently. Reading flow: Setup, connection attempts, assertion, and cleanup follow a natural sequence. Dense imports, long generic declarations, and the compound type-check condition slightly interrupt readability.
Run 3
Code Structure: Methods cleanly separate test execution, connection assertions, and factory selection; cleanup is organized in finally. Nesting: Mostly shallow, with modest nesting in the anonymous runner and factory filtering. Clarity of intent: The test name and AlreadyConnectedException assertion clearly communicate the purpose, but abbreviated identifiers (sb, cb, sc, cc) and computing port zero as a + b obscure otherwise simple operations. Code length: Reasonably concise, though the anonymous runner and repeated generic types add verbosity, and the two constants are unnecessary. Action granularity: Most lines perform one logical action; chained channel operations remain understandable. Reading flow: Setup, connection, repeated connection, assertion, and cleanup follow a natural sequence. Dense generic declarations, minimally separated imports, and the indirect port expression slightly interrupt readability.