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

Optionally close connections after a set number of send attempts #118

Merged

Conversation

jchambers
Copy link
Owner

This is (I think) the last in a series of changes intended to work around an APNs design issue where we can't know if connections are still alive. The idea here is to (optionally) close connections after a user-configurable number of notifications have been sent.

While #116 closes connections that sit idle, connections may never become idle in applications that generate lots of push notifications. This change allows very active connections to shut down after a set number of send attempts, so even applications that never allow for idle connections will have a reliable way to cycle connections.

EDIT: Changes are probably best viewed with whitespace-only changes hidden.

…es/pushy into close_after_send_attempt_limit

if (this.configuration.getSendAttemptLimit() != null && ++this.sendAttempts >= this.configuration.getSendAttemptLimit()) {
log.debug("{} reached send attempt limit and will shut down gracefully.", this.name);
this.shutdownGracefully();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we want to shutdown gracefully if a failure notification has already been sent? Should this parallel #117 and shutdown immediately if the failure notification has already been sent?

Copy link
Owner Author

Choose a reason for hiding this comment

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

I'm not following; we're not really considering whether we've sent a known-bad notification at this point. It's true that we're aware of it in the else block at line 556, but that's just for deciding if we should attempt to write the maybe-good notification the caller was trying to send.

In any case, even if a known-bad notification has been sent, we don't want to force a shutdown (before the timeout, anyhow) because we might still be waiting for the APNs gateway to respond to our known-bad notification. Make sense? I'm worried that I'm missing your point.

Copy link
Contributor

Choose a reason for hiding this comment

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

Discussed offline: The changes in #117 will take care of the shutdown gracefully timeout case.

Jon Chambers added 2 commits September 9, 2014 12:00
…es/pushy into close_after_send_attempt_limit

Conflicts:
	src/main/java/com/relayrides/pushy/apns/ApnsConnectionConfiguration.java
	src/test/java/com/relayrides/pushy/apns/ApnsConnectionTest.java
@jchambers
Copy link
Owner Author

@AndreaLev Feeling good about this one?

if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
final ApnsConnectionConfiguration other = (ApnsConnectionConfiguration) obj;
ApnsConnectionConfiguration other = (ApnsConnectionConfiguration) obj;
Copy link
Contributor

Choose a reason for hiding this comment

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

Very minor: Why did you remove the final? It doesn't look like you're modifying other

Copy link
Owner Author

Choose a reason for hiding this comment

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

Oops. Just let Eclipse generate a new equals method, and I guess it must have stripped it. Not intentional. Restored in 2f64f36.

@AndreaLev
Copy link
Contributor

👍

jchambers added a commit that referenced this pull request Sep 19, 2014
Optionally close connections after a set number of send attempts
@jchambers jchambers merged commit 5cf6ce1 into close_connections_when_inactive Sep 19, 2014
@jchambers jchambers deleted the close_after_send_attempt_limit branch May 19, 2016 02:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants