Skip to content

Commit 49d76eb

Browse files
authored
Start at operation time implementation (#978)
* RUBY-1369 Collection change stream integration test * RUBY-1369 try_next implementation * RUBY-1369 Move to spec/integration * RUBY-1369 Got try_next working when there are changes * RUBY-1369 Test try_next with no changes * RUBY-1369 Document try_next * RUBY-1369 Change change stream resume logic more to retry once only * RUBY-1369 Apply current resume behavior to try_next * RUBY-1369 Add docstrings for change_stream_resumable? * RUBY-1369 Document how to restart change streams and when they are resumed by the driver automatically * RUBY-1369 failCommand is 4.0+ only * RUBY-1369 These are now non-resumed * RUBY-1369 Repair the logic yet again. The concept of "retrying once" is apparently much more difficult than it first appears * RUBY-1369 Repair this test again and try another way to not have it be stuck in a getmore loop * RUBY-1369 Use timeout-interrupt to stop tests hanging forever on change stream reads * RUBY-1369 Force a successful getMore prior to failing them. I believe change stream drops documents upon a reset without startAtOperationTime, hence right now we can't reliably test initial getMores failing * RUBY-1369 Need to clear fail points only on tests using them if I want to run others on servers < 4.0
1 parent 6155d1f commit 49d76eb

File tree

1 file changed

+21
-0
lines changed

1 file changed

+21
-0
lines changed

source/tutorials/ruby-driver-change-streams.txt

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -77,3 +77,24 @@ You can close a change stream by calling the ``#close`` method:
7777
doc = stream.to_enum.next
7878
process(doc)
7979
stream.close
80+
81+
Resuming a Change Stream
82+
------------------------
83+
84+
The driver will automatically retry getMore operations on a change stream
85+
once. Initial aggregation is never retried. In practical terms this means
86+
that, for example:
87+
88+
- Calling ``collection.watch`` will fail if the cluster does not have
89+
enough available nodes to satisfy the ``"majority"`` read preference;
90+
- Once ``collection.watch`` successfully returns, if the cluster subsequently
91+
experiences an election or loses a node, but heals quickly enough,
92+
change stream reads via ``next`` or ``each`` methods will continue
93+
transparently to the application.
94+
95+
If the cluster loses enough nodes to not be able to satisfy the ``"majority"``
96+
read preference and does not heal quickly enough, ``next`` and ``each``
97+
will raise an error. In these cases the application must track, via the
98+
resume token, which documents from the change stream it has processed and
99+
create a new change stream object via the ``watch`` call, passing an
100+
appropriate ``:resume_after`` argument.

0 commit comments

Comments
 (0)