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

RTN15f #438

Merged
merged 4 commits into from
Apr 29, 2016
Merged

RTN15f #438

merged 4 commits into from
Apr 29, 2016

Conversation

ricardopereira
Copy link
Contributor

No description provided.

var resumed = false
waitUntil(timeout: testTimeout) { done in
client.connection.once(.Connected) { _ in
channel.publish(nil, data: "message") { _ in
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure I follow hot his method is called twice, can you explain?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is called twice? Can you clarify? The publish only receives the ACK (callback is called) after the connection has been resumed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe I'm wrong. @tcard do you have any suggestion for this one?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand @mattheworiordan 's point either. This looks good to me. The message is sent in one transport, which is immediately dropped. The fact that publish's callback is called after the connection is resumed proves that the library resent the message in the new transport.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I misunderstood the code. However, as the spec states that the message is resent on the new transport, can we also include that check so that this test code explains what is happening i.e. it's not that on a new connection the ACK is sent, it's actually an ACK that is received from the message being resent. Do you agree?

Copy link
Contributor Author

@ricardopereira ricardopereira Apr 28, 2016

Choose a reason for hiding this comment

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

Done bcd8a7e.

@tcard tcard merged commit bc22dae into master Apr 29, 2016
@tcard
Copy link
Contributor

tcard commented Apr 29, 2016

LGTM (by the way).

@tcard tcard deleted the rtn15f branch April 29, 2016 16:43
tcard pushed a commit that referenced this pull request May 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants