Skip to content
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

Add a backpressure mechanism for channel writes #383

Merged
merged 1 commit into from
Dec 14, 2016

Conversation

stepheno
Copy link
Contributor

  • Checks the status of Channel.isWritable() before attempting to write a
    notification to the channel. If isWritable() returns false, return a new failed
    future with a cause of ClientBusyException. The presence of this exception is
    a signal to back off write attempts until the underlying channel has sucessfully returned
    to its low water mark
  • Adds ApnsClientBuilder#setChannelWriteBufferWatermark for setting
    the channel watermark levels
  • Adds ApnsClientBuilder#setByteBufferAllocator for setting the buffer
    allocator of the netty channel

* Checks the status of `Channel.isWritable()` before attempting to write a
notification to the channel. If `isWritable()` returns false, return a new failed
future with a cause of `ClientBusyException`. The presence of this exception is
a signal to back off write attempts until the underlying channel has sucessfully returned
to its low water mark
* Adds `ApnsClientBuilder#setChannelWriteBufferWatermark` for setting
 the channel watermark levels
* Adds `ApnsClientBuilder#setByteBufferAllocator` for setting the buffer
 allocator of the netty channel
@jchambers jchambers added this to the v0.9 milestone Nov 15, 2016
@jchambers
Copy link
Owner

On the whole, this looks good to me! I'll give it a more detailed read as soon as I can (which will most likely be Friday). Thanks very much for the contribution!

@stepheno
Copy link
Contributor Author

Thanks for taking a look. I just noticed that you have a 0.8.2 release milestone planned. Mind if update to target that release instead(just changing the @SInCE annotations in the comments)?

@jchambers jchambers modified the milestones: v0.9.1, v0.9, v0.8.2 Dec 10, 2016
@jchambers
Copy link
Owner

@stepheno I went back and forth on this a few times, but I think it makes sense to include in 0.8.2.

Copy link
Owner

@jchambers jchambers left a comment

Choose a reason for hiding this comment

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

With sincere apologies for the long delay on reviewing this in detail, this looks good to me from a technical perspective. I think we might want to polish the docs just a little but more, and as you pointed out, change the @since version. Otherwise, I think we're good!

Thanks very much for the contribution!

*
* @param message a short, human-readable explanation of the cause of this exception
*/
public ClientBusyException(final String message) {
Copy link
Owner

Choose a reason for hiding this comment

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

It looks like we never use this constructor; could we just drop it? If all we're left with is the default passthrough constructor, we could probably drop that, too.

}

/**
* Sets the buffer usage watermark range for the underlying netty channel
Copy link
Owner

Choose a reason for hiding this comment

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

Can we be a little more descriptive here, too? This seems like a good place to mention the existence of ClientBusyException, for example.

@@ -349,6 +354,34 @@ public ApnsClientBuilder setGracefulShutdownTimeout(final long gracefulShutdownT
}

/**
* Sets the buffer allocator for the underlying netty channel
Copy link
Owner

Choose a reason for hiding this comment

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

Can we be a little more descriptive here and maybe explain why a user would want to do this, or what the consequences might be? Also, as a super minor thing, mind adding a period to the end of the sentence? ;)

@jchambers
Copy link
Owner

Actually, @stepheno, the things I'm asking for here are pretty minor. I'll go ahead and make the doc changes myself. Please consider yourself off the hook. I'll cobble a thing together and merge/close this shortly. Thanks again!

@stepheno
Copy link
Contributor Author

stepheno commented Dec 13, 2016 via email

@jchambers
Copy link
Owner

Hey, @stepheno, can you tell me more about the use case for setting a custom byte buffer allocator? To my knowledge, the only options are "pooled" and "unpooled," and those can be selected globally by setting the io.netty.allocator.type system property:

java -Dio.netty.allocator.type=pooled -jar totally-sweet-push-notification-thing.jar

Do you have a use case in mind where somebody (a) would need a non-default allocator and (b) would need a different one than the JVM-wide default? To be clear, I'm totally open to this, but I want to double-check that the need isn't already met by the -Dio.netty.allocator.type thing.

@stepheno
Copy link
Contributor Author

Hey @jchambers, you're right about the global io.netty.allocator.type system property. There's not really a need to add functionality to the builder for this case. Feel free to rip it out.

@jchambers jchambers merged commit 0ee8b41 into jchambers:master Dec 14, 2016
@jchambers
Copy link
Owner

And we're good. I did the cleanup stuff in 5882679; please let me know if anything looks amiss to you. Cheers!

@jchambers
Copy link
Owner

Er… by which I actually mean 1e221a3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants