Skip to content

Fix the read timeout implementation in NettyStream #636

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jan 20, 2021
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
200 changes: 141 additions & 59 deletions driver-core/src/main/com/mongodb/connection/netty/NettyStream.java
Original file line number Diff line number Diff line change
Expand Up @@ -24,27 +24,29 @@
import com.mongodb.MongoSocketOpenException;
import com.mongodb.MongoSocketReadTimeoutException;
import com.mongodb.ServerAddress;
import com.mongodb.annotations.ThreadSafe;
import com.mongodb.connection.AsyncCompletionHandler;
import com.mongodb.connection.SocketSettings;
import com.mongodb.connection.SslSettings;
import com.mongodb.connection.Stream;
import com.mongodb.lang.Nullable;
import io.netty.bootstrap.Bootstrap;
import io.netty.buffer.ByteBufAllocator;
import io.netty.buffer.CompositeByteBuf;
import io.netty.buffer.PooledByteBufAllocator;
import io.netty.channel.Channel;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelFutureListener;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelOption;
import io.netty.channel.ChannelPipeline;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.SimpleChannelInboundHandler;
import io.netty.channel.socket.SocketChannel;
import io.netty.handler.ssl.SslHandler;
import io.netty.handler.timeout.ReadTimeoutException;
import io.netty.util.concurrent.EventExecutor;
import org.bson.ByteBuf;

import javax.net.ssl.SSLContext;
Expand All @@ -58,29 +60,72 @@
import java.util.List;
import java.util.Queue;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.Future;
import java.util.concurrent.ScheduledFuture;

import static com.mongodb.assertions.Assertions.isTrueArgument;
import static com.mongodb.internal.connection.SslHelper.enableHostNameVerification;
import static com.mongodb.internal.connection.SslHelper.enableSni;
import static java.util.concurrent.TimeUnit.MILLISECONDS;

/**
* A Stream implementation based on Netty 4.0.
* Just like it is for the {@link java.nio.channels.AsynchronousSocketChannel},
* concurrent pending<sup>1</sup> readers
* (whether {@linkplain #read(int, int) synchronous} or {@linkplain #readAsync(int, AsyncCompletionHandler) asynchronous})
* are not supported by {@link NettyStream}.
* However, this class does not have a fail-fast mechanism checking for such situations.
* <hr>
* <sup>1</sup>We cannot simply say that read methods are not allowed be run concurrently because strictly speaking they are allowed,
* as explained below.
* <pre>{@code
* NettyStream stream = ...;
* stream.readAsync(1, new AsyncCompletionHandler<ByteBuf>() {//inv1
* @Override
* public void completed(ByteBuf o) {
* stream.readAsync(//inv2
* 1, ...);//ret2
* }
*
* @Override
* public void failed(Throwable t) {
* }
* });//ret1
* }</pre>
* Arrows on the diagram below represent happens-before relations.
* <pre>{@code
* int1 -> inv2 -> ret2
* \--------> ret1
* }</pre>
* As shown on the diagram, the method {@link #readAsync(int, AsyncCompletionHandler)} runs concurrently with
* itself in the example above. However, there are no concurrent pending readers because the second operation
* is invoked after the first operation has completed reading despite the method has not returned yet.
*/
final class NettyStream implements Stream {
private static final String READ_HANDLER_NAME = "ReadTimeoutHandler";
private static final int NO_SCHEDULE_TIMEOUT = -1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0 defaults to no timeout can this also be zero?

Also can we name this to be explicit that it represents no timeout for reads?
NO_READ_TIMEOUT = 0

private final ServerAddress address;
private final SocketSettings settings;
private final SslSettings sslSettings;
private final EventLoopGroup workerGroup;
private final Class<? extends SocketChannel> socketChannelClass;
private final ByteBufAllocator allocator;

private volatile boolean isClosed;
private boolean isClosed;
private volatile Channel channel;

private final LinkedList<io.netty.buffer.ByteBuf> pendingInboundBuffers = new LinkedList<io.netty.buffer.ByteBuf>();
private volatile PendingReader pendingReader;
private volatile Throwable pendingException;
/* The fields pendingReader, pendingException are always written/read inside synchronized blocks
* that use the same NettyStream object, so they can be plain.*/
private PendingReader pendingReader;
private Throwable pendingException;
/* The fields readTimeoutTask, readTimeoutMillis are each written only in the ChannelInitializer.initChannel method
* (in addition to the write of the default value), and read only when NettyStream users read data,
* or Netty event loop handles incoming data. Since actions done by the ChannelInitializer.initChannel method
* are ordered (in the happens-before order) before user read actions and before event loop actions that handle incoming data,
* these fields can be plain.*/
@Nullable
private ReadTimeoutTask readTimeoutTask;
private long readTimeoutMillis;

NettyStream(final ServerAddress address, final SocketSettings settings, final SslSettings sslSettings, final EventLoopGroup workerGroup,
final Class<? extends SocketChannel> socketChannelClass, final ByteBufAllocator allocator) {
Expand Down Expand Up @@ -143,6 +188,7 @@ private void initializeChannel(final AsyncCompletionHandler<Void> handler, final
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(final SocketChannel ch) {
final ChannelPipeline pipeline = ch.pipeline();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: No need for local final variables.

Copy link
Member Author

@stIncMale stIncMale Jan 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to use a reference to the channel's pipeline in multiple places in this method. While calling ch.pipeline() each time we need it is correct, it is an unnecessary call, because we know that the method returns the same reference. We may make some assumptions about the method implementation/performance by looking at the source code, but we should treat it as subject for change, and something that we may believe is "free" for now, may not be free in the future.

Additionally, not calling a method multiple times reduces the number of usages that IDE finds when we want to find usages of the method. This simplifies code navigation.

As for the final modifier on local variables, it's a simple way to tell the reader that the variable is assigned once and only once.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This codebase has been created by many authors, it looks homogenous because all the developers have tread lightly on the codebase and kept the code style consistent. Using final for local variables isn't a style that has been adopted in the past.

However, with the base line now being java 8 and the need for local final variable in closures perhaps this is a style we should adopt. It is more explicit as you say.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to consider final local variables as a standard going forward, but currently it's our standard not to, so let's stick with that for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, note that IntellJ now differentiates between mutated and effectively final local variables by underlining the former.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the final modifier. Is there a document with the style specified (not all style aspects are checked automatically)? I apologize for making not compliant changes, but I have not seen the document that specifies it. If there is none, I'll be picking up the style as I go.

if (sslSettings.isEnabled()) {
SSLEngine engine = getSslContext().createSSLEngine(address.getHost(), address.getPort());
engine.setUseClientMode(true);
Expand All @@ -152,13 +198,24 @@ public void initChannel(final SocketChannel ch) {
enableHostNameVerification(sslParameters);
}
engine.setSSLParameters(sslParameters);
ch.pipeline().addFirst("ssl", new SslHandler(engine, false));
pipeline.addFirst("ssl", new SslHandler(engine, false));
}

int readTimeout = settings.getReadTimeout(MILLISECONDS);
final long readTimeoutMillis;
if (readTimeout > 0) {
ch.pipeline().addLast(READ_HANDLER_NAME, new ReadTimeoutHandler(readTimeout));
readTimeoutMillis = readTimeout;
/* We need at least one handler before (in the inbound evaluation order) the InboundBufferHandler,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand this comment. Where are we firing exception events? What would be the observed behavior if we didn't have this handler?

Copy link
Member Author

@stIncMale stIncMale Jan 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where are we firing exception events?
ctx.fireExceptionCaught(ReadTimeoutException.INSTANCE) fires it.

The only way for us to fire an exception event in Netty not as a result of handing an inbound/outbound event in ChannelInboundHandler/ChannelOutboundHandler, but on demand, is to call ChannelHandlerContext.fireExceptionCaught. This method results "in having the ChannelInboundHandler.exceptionCaught(ChannelHandlerContext, Throwable) method called of the next ChannelInboundHandler contained in the ChannelPipeline of the Channel". So we need to store a reference to a context of a handler (we store it in ReadTimeoutTask.ctx), which is a legit approach: "You can keep the ChannelHandlerContext for later use, such as triggering an event outside the handler methods, even from a different thread.".

Now we need to decide which handler's context we will use. Our InboundBufferHandler knows how to process exceptions, so we need timeout exception events to be forwarded to this handler, which means we cannot use its context for firing such events (this follows from the docs quoted above). 👉 At this point you may read the comment again, and it will probably be clear this time. Hope this helps, but if not, let's have a call.

What would be the observed behavior if we didn't have this handler?

We would still need a context, and since InboundBufferHandler is the only handler that is always in the pipeline, we would pick its context. As a result, InboundBufferHandler would not handle timeout exceptions because its context would be forwarding them to the next handler, which does not exist, and they would be "discarded silently, or logged if it needs your attention" (in which cases Netty considers that an exception "needs attention" is unspecified).

* so that we can fire exception events (they are inbound events) using its context and the InboundBufferHandler
* receives them. SslHandler is not always present, so adding a NOOP handler.*/
pipeline.addLast(new ChannelInboundHandlerAdapter());
readTimeoutTask = new ReadTimeoutTask(pipeline.lastContext());
} else {
readTimeoutMillis = NO_SCHEDULE_TIMEOUT;
}
ch.pipeline().addLast(new InboundBufferHandler());
NettyStream.this.readTimeoutMillis = readTimeoutMillis;

pipeline.addLast(new InboundBufferHandler());
}
});
final ChannelFuture channelFuture = bootstrap.connect(nextAddress);
Expand All @@ -184,9 +241,10 @@ public boolean supportsAdditionalTimeout() {
}

@Override
public ByteBuf read(final int numBytes, final int additionalTimeout) throws IOException {
public ByteBuf read(final int numBytes, final int additionalTimeoutMillis) throws IOException {
isTrueArgument("additionalTimeoutMillis must not be negative", additionalTimeoutMillis >= 0);
FutureAsyncCompletionHandler<ByteBuf> future = new FutureAsyncCompletionHandler<ByteBuf>();
readAsync(numBytes, future, additionalTimeout);
readAsync(numBytes, future, combinedTimeout(readTimeoutMillis, additionalTimeoutMillis));
return future.get();
}

Expand All @@ -211,18 +269,32 @@ public void operationComplete(final ChannelFuture future) throws Exception {

@Override
public void readAsync(final int numBytes, final AsyncCompletionHandler<ByteBuf> handler) {
readAsync(numBytes, handler, 0);
readAsync(numBytes, handler, readTimeoutMillis);
}

private void readAsync(final int numBytes, final AsyncCompletionHandler<ByteBuf> handler, final int additionalTimeout) {
scheduleReadTimeout(additionalTimeout);
/**
* @param numBytes Must be equal to {@link #pendingReader}{@code .numBytes} when called by a Netty channel handler.
* @param handler Must be equal to {@link #pendingReader}{@code .handler} when called by a Netty channel handler.
* @param readTimeoutMillis Must be equal to {@link #NO_SCHEDULE_TIMEOUT} when called by a Netty channel handler.
* Timeouts may be scheduled only by the public read methods. Taking into account that concurrent pending
* readers are not allowed, there must not be a situation when threads attempt to schedule a timeout
* before the previous one is either cancelled or completed.
*/
private void readAsync(final int numBytes, final AsyncCompletionHandler<ByteBuf> handler, final long readTimeoutMillis) {
ByteBuf buffer = null;
Throwable exceptionResult = null;
synchronized (this) {
exceptionResult = pendingException;
PendingReader pendingReader = this.pendingReader;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Does this need to be made a local variable? If so seems we've used localPendingReader elsewhere to make it clearer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I am using local variables for shared state is to reduce the number of read usages we can see in the code (including the "Find usages" search in an IDE). The fewer code pieces include reads from or writes to a shared variable, the easier it is (at least to me) to think about the correctness of concurrent code.

The reason I did not call it localPendingReader is because local adds verbosity without adding any information: we can immediately see that this is a local variable on the line it is declared, and on the other lines where it is used IntelliJ IDEA IDE differentiates local and object variables (by default by using different boldness of the font).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a cognitive load and cost to a code base by reusing the same named variable. It also adds future risk to the codebase as the localization of the variable may be changed.

Adding local does add verbosity but I disagree because it does add extra information, its explicit. Explicit should be preferred over implicit. Especially as you can't guarantee users have the same IDE or even settings in their IDE as you.

So please make it explicit, it costs nothing and improves the readability of the code for future development.

Copy link
Collaborator

@jyemin jyemin Jan 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our practice generally in this code base is to minimize use of local variables. I can see the argument here in favor, since this is state that is protected by a lock, but at the same time I do find the style odd, particularly lines 288-290 below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the pendingReader local variable.

if (exceptionResult == null) {
if (!hasBytesAvailable(numBytes)) {
pendingReader = new PendingReader(numBytes, handler);
if (pendingReader == null) {//called by a public read method
pendingReader = new PendingReader(numBytes, handler, scheduleReadTimeout(readTimeoutTask, readTimeoutMillis));
this.pendingReader = pendingReader;
} else {//called by a Netty channel handler
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This else statement can be removed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it can be, but does removing it make the code clearer? This code is not so trivial, and having comments that express what's going on, or even state some invariants and possible interpretations in case they are violated, appears to be useful. What are the downsides of having code comments like this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally don't inline comment in the code because its considered a code smell. The code should be readable in intent, however there are scenarios where you may want to add comments. In general methods / classes have comments describing the logic.

I'll leave this one to you thinks best, It may be useful in x years when we revisit this code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding this else statement I don't think it adds to the code as contains no logic.

A single comment checking is if(pendingReader == null) should suffice.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you really want the commented asserts to remain as documentation, how about also commenting out the else that contains them?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the else block and the comments within.

//assert pendingReader.numBytes == numBytes : "Concurrent pending readers are not allowed";
//assert pendingReader.handler == handler : "Concurrent pending readers are not allowed";
}
} else {
CompositeByteBuf composite = allocator.compositeBuffer(pendingInboundBuffers.size());
int bytesNeeded = numBytes;
Expand All @@ -245,13 +317,16 @@ private void readAsync(final int numBytes, final AsyncCompletionHandler<ByteBuf>
buffer = new NettyByteBuf(composite).flip();
}
}
if (!(exceptionResult == null && buffer == null)//the read operation has completed
&& pendingReader != null) {//we need to clear the pending reader
cancel(pendingReader.timeout);
this.pendingReader = null;
}
}
if (exceptionResult != null) {
disableReadTimeout();
handler.failed(exceptionResult);
}
if (buffer != null) {
disableReadTimeout();
handler.completed(buffer);
}
}
Expand All @@ -275,14 +350,12 @@ private void handleReadResponse(final io.netty.buffer.ByteBuf buffer, final Thro
} else {
pendingException = t;
}
if (pendingReader != null) {
localPendingReader = pendingReader;
pendingReader = null;
}
localPendingReader = pendingReader;
}

if (localPendingReader != null) {
readAsync(localPendingReader.numBytes, localPendingReader.handler);
//timeouts may be scheduled only by the public read methods
readAsync(localPendingReader.numBytes, localPendingReader.handler, NO_SCHEDULE_TIMEOUT);
}
}

Expand Down Expand Up @@ -358,10 +431,14 @@ public void exceptionCaught(final ChannelHandlerContext ctx, final Throwable t)
private static final class PendingReader {
private final int numBytes;
private final AsyncCompletionHandler<ByteBuf> handler;
@Nullable
private final ScheduledFuture<?> timeout;

private PendingReader(final int numBytes, final AsyncCompletionHandler<ByteBuf> handler) {
private PendingReader(
final int numBytes, final AsyncCompletionHandler<ByteBuf> handler, @Nullable final ScheduledFuture<?> timeout) {
this.numBytes = numBytes;
this.handler = handler;
this.timeout = timeout;
}
}

Expand Down Expand Up @@ -445,47 +522,52 @@ public void operationComplete(final ChannelFuture future) {
}
}

private void scheduleReadTimeout(final int additionalTimeout) {
adjustTimeout(false, additionalTimeout);
private static void cancel(@Nullable final Future<?> f) {
if (f != null) {
f.cancel(false);
}
}

private void disableReadTimeout() {
adjustTimeout(true, 0);
private static long combinedTimeout(final long timeout, final int additionalTimeout) {
if (timeout == NO_SCHEDULE_TIMEOUT || additionalTimeout == NO_SCHEDULE_TIMEOUT) {
return NO_SCHEDULE_TIMEOUT;
} else {
return Math.addExact(timeout, additionalTimeout);
}
}

private void adjustTimeout(final boolean disable, final int additionalTimeout) {
if (isClosed) {
return;
}
ChannelHandler timeoutHandler = channel.pipeline().get(READ_HANDLER_NAME);
if (timeoutHandler != null) {
final ReadTimeoutHandler readTimeoutHandler = (ReadTimeoutHandler) timeoutHandler;
final ChannelHandlerContext handlerContext = channel.pipeline().context(timeoutHandler);
EventExecutor executor = handlerContext.executor();

if (disable) {
if (executor.inEventLoop()) {
readTimeoutHandler.removeTimeout(handlerContext);
} else {
executor.submit(new Runnable() {
@Override
public void run() {
readTimeoutHandler.removeTimeout(handlerContext);
}
});
}
} else {
if (executor.inEventLoop()) {
readTimeoutHandler.scheduleTimeout(handlerContext, additionalTimeout);
} else {
executor.submit(new Runnable() {
@Override
public void run() {
readTimeoutHandler.scheduleTimeout(handlerContext, additionalTimeout);
}
});
}
private static ScheduledFuture<?> scheduleReadTimeout(@Nullable final ReadTimeoutTask readTimeoutTask, final long timeoutMillis) {
if (timeoutMillis == NO_SCHEDULE_TIMEOUT) {
return null;
} else {
//assert readTimeoutTask != null : "readTimeoutTask must be initialized if read timeouts are enabled";
return readTimeoutTask.schedule(timeoutMillis);
}
}

@ThreadSafe
private static final class ReadTimeoutTask implements Runnable {
private final ChannelHandlerContext ctx;

private ReadTimeoutTask(final ChannelHandlerContext timeoutChannelHandlerContext) {
ctx = timeoutChannelHandlerContext;
}

@Override
public void run() {
try {
if (ctx.channel().isOpen()) {
ctx.fireExceptionCaught(ReadTimeoutException.INSTANCE);
ctx.close();
}
} catch (final Throwable t) {
ctx.fireExceptionCaught(t);
}
}

private ScheduledFuture<?> schedule(final long timeoutMillis) {
//assert timeoutMillis > 0 : timeoutMillis;
return ctx.executor().schedule(this, timeoutMillis, MILLISECONDS);
}
}
}
Loading