-
Notifications
You must be signed in to change notification settings - Fork 40
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
issues/170: Fixed message serial out of sync after recover #175
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This change might still be wrong. Paddy and I are discussing. |
What do you reckon to that Paddy? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but pls see comments.
@@ -271,6 +272,7 @@ public void run() { | |||
***************************************/ | |||
|
|||
public void onMessage(ProtocolMessage message) throws AblyException { | |||
Log.v(TAG, "onMessage(): " + new String(ProtocolSerializer.writeJSON(message))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the way that this serialises every message even though the log level doesn't require it to be emitted. I think it has to be done conditionally on the log level, or the log API has to take a format string and arguments so expansion is under control of the logger.
* connection, and thus one more than the highest message serial | ||
* in the queue. | ||
*/ | ||
public synchronized void reset(long oldMsgSerial) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think reset()
should take an ErrorInfo
argument and pass that to the nack, and then the specific error is determined by whoever calls reset()
. There will be different situations that will require different error messages/codes.
This fixes part of #169
#170 had a problem where reeonnection from suspended and explicit channel recovery stops CompletionListener.onSuccess() being called for messages published after that. The problem was that the message serial in ConnectionManager and PendingMessageQueue got out of sync -- only the former was reset back to 0, so then PendingMessageQueue got confused by the message serial in an ack after a publish, and the callback was not called. Fixed by ensuring that msgSerial only gets reset when the connection id changes on connect, and then the PendingMessageQueue is reset at the same time. Also any pending messages (ones that have been sent but not acked) at that time are failed.
#170 One test for the recover case that was broken, and one test for the resume case that was probably not broken.
@paddy fixed your comments. |
Thanks |
Also protocol message logging.