-
Notifications
You must be signed in to change notification settings - Fork 593
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
Fix bugs in idle timeout logic (C#) #3156
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -1941,6 +1941,9 @@ private bool validate(int operation) | |||
throw new MarshalException($"Received ValidateConnection message with unexpected size {size}."); | ||||
} | ||||
TraceUtil.traceRecv(_readStream, this, _logger, _traceLevels); | ||||
|
||||
// Client connection starts sending heartbeats once it's received the ValidateConnection message. | ||||
_idleTimeoutTransceiver?.scheduleHeartbeat(); | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can _idleTimeoutTransceiver ever be null here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it's null when the idle timeout is <=0 (i.e., disabled) ice/csharp/src/Ice/ConnectionI.cs Line 1410 in 54548fe
|
||||
} | ||||
} | ||||
|
||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -61,17 +61,8 @@ public void finishRead(Buffer buf) | |
|
||
public ConnectionInfo getInfo() => _decoratee.getInfo(); | ||
|
||
public int initialize(Buffer readBuffer, Buffer writeBuffer, ref bool hasMoreData) | ||
{ | ||
int op = _decoratee.initialize(readBuffer, writeBuffer, ref hasMoreData); | ||
|
||
if (op == SocketOperation.None) // connected | ||
{ | ||
rescheduleWriteTimer(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Bug 1: |
||
} | ||
|
||
return op; | ||
} | ||
public int initialize(Buffer readBuffer, Buffer writeBuffer, ref bool hasMoreData) => | ||
_decoratee.initialize(readBuffer, writeBuffer, ref hasMoreData); | ||
|
||
public string protocol() => _decoratee.protocol(); | ||
|
||
|
@@ -126,7 +117,10 @@ internal IdleTimeoutTransceiverDecorator(Transceiver decoratee, ConnectionI conn | |
|
||
internal void enableIdleCheck() | ||
{ | ||
if (!idleCheckEnabled && _readTimer is not null) | ||
// idleCheckEnabled is already true when enableIdleCheck() is called on a TCP server connection that becomes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Bug 2: For example, a TCP server connection can become active and not read anything ever. This should trigger an idle timeout. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand this second fix. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Take a TCP server connection, where the client doesn't send any request or ValidateConnection frame. Maybe because it's not an Ice client. In this case, when do we schedule the very fist idle check? Can't be in a read since we don't read anything. A good spot is when the ConnectionI becomes active for the first time and calls enableIdleCheck. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. but why is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's set to true by the IdleTimeoutTransceiverDecorator constructor. Maybe a better fix would be to set it to false in the constructor, and rely on the first enableIdleCheck() (from the first activate) to flip it to true? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed as suggested: the constructor no longer sets idleCheckEnabled to true. |
||
// Active for the first time. | ||
|
||
if (_readTimer is not null) | ||
{ | ||
rescheduleReadTimer(); | ||
idleCheckEnabled = true; | ||
|
@@ -142,6 +136,8 @@ internal void disableIdleCheck() | |
} | ||
} | ||
|
||
internal void scheduleHeartbeat() => rescheduleWriteTimer(); | ||
|
||
private void cancelReadTimer() => _readTimer!.Change(Timeout.InfiniteTimeSpan, Timeout.InfiniteTimeSpan); | ||
|
||
private void cancelWriteTimer() => _writeTimer.Change(Timeout.InfiniteTimeSpan, Timeout.InfiniteTimeSpan); | ||
|
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.
even if it doesn't write anything (a rare situation).
On the server side, the writing of the initial ValidateConnection message schedules the first heartbeat.