[JAVA-3828] Client Side Operations Timeout Created: 31/Aug/20  Updated: 08/Feb/24

Status: Implementing
Project: Java Driver
Component/s: CSOT, Retryability
Affects Version/s: None
Fix Version/s: None

Type: Epic Priority: Major - P3
Reporter: Esha Bhargava Assignee: Ross Lawley
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVA-4048 Client Side Operations Timeout Closed
is duplicated by JAVA-2795 Add a query parameter to limit the ti... Closed
Issue split
Quarter: FY24Q3
Upstream Changes Summary:

DRIVERS-555:
NA

Documentation Changes Summary: 1. What would you like to communicate to the user about this feature?
2. Would you like the user to see examples of the syntax and/or executable code and its output?
3. Which versions of the driver/connector does this apply to?
Start date:
End date:
Calendar Time: 26 weeks, 1 day
Scope Cost Estimate: 9
Cost to Date: 22
Final Cost Estimate: 30
Cost Threshold %: 200
Detailed Project Statuses:

Engineer(s): Ross, Slava

Summary: Allow users to configure the timeout on operations by using a single timeout setting.

2024-02-02: No change to target date

  • SDAM, CRUD, GridFS and misc. refactor tasks to support timeouts completed
  • Client-side encryption, transactions + convenient API in progress
  • Handshake and Auth in code review

2024-01-19: Updated target end date to 2024-03-01

  • Working on Auth, Connection checkout and handshake, CSFLE
  • Connection Pool, SDAM, CRUD in review
  • No blockers, updated with revised estimate (additional 10 eng wks)

2024-01-01: No change to target end date

  • GridFS synchronous in review
    • reactive streams in progress
  • CRUD deprecations in review
  • Command Execution merged
  • Investigating sync adapter implementation
    • New test added, currently in review

2023-12-08: No change to target end date

  • Retryable-reads and retryable-writes updates to support CSOT currently in review
  • Command Execution updates to support CSOT in progress
  • Up next: CRUD and SDAM

2023-11-22: 

  • In progress:
    • Update existing timeouts according to the retryable-reads and retryable-writes specification to support CSOT
    • Cursor handling and timeoutModes now in review

2023-11-10: 

  • Batch cursor refactor completed
  • Maxim has handed off his part of CSOT to Slava in advance of his upcoming leave
  • In progress:
    • Update existing timeouts according to the retryable-reads and retryable-writes specification to support CSOT
  • Corrected the estimated final cost to 23 weeks
    • No change to the target end date here, est. final cost should have been updated to 23 when we got the revised estimate

2023-10-30: Updated target end date to 2024-01-19

  • Refactoring to obtain connectTimeoutMS from TimeoutContext rather than setting directly
  • Batch cursor refactor in progress to simplify future CSOT work

2023-10-13: Updated target end date to 2023-12-15

  • Team has broken down remaining work and updated estimate
  • Async and sync command cursors have been brought much more into line with lots of code reuse
    • Brings a single batch cursor to sync also bringing async / sync into line
  • Server selection is in progress using the TimeoutContext now available in OperationContext

2023-09-29: Updated target end date to 2023-12-01

  • TimeoutMS is in the settings and used in operations calculating maxTimeMS
  • The refactor to propagate an OperationContext down through the operation layer into the connection layer was merged earlier this week
  • Server selection is in progress using the TimeoutContext now available in OperationContext
  • The end date is based on a rough estimate atm and will be revised once the team has more confidence in the estimates

2023-09-15: Set target date to 2023-10-13

  • Prerequisite refactors necessary to implement CSOT have been completed
    • Still need to decide between using timepoints vs deadlines (decision deferred for now)
  • ServerSelection and CRUD in progress
  • Pushed planned end date out as this will not be done by September 22nd

Engineer(s): Ross, Maxim

Summary: Allow users to configure the timeout on operations by using a single timeout setting.

2023-09-01: Set target date to 2023-09-22

  • Refactor of OperationHelper & CommandOperationHelper completed
  • Cursor refactor and representing timeouts internally as deadlines in progress
  • Currently Ross is the only one working on this and Maxim will begin upon his return from PTO

Engineer(s): Ross

Summary: Allow users to configure the timeout on operations by using a single timeout setting.

Cost in Eng Weeks: 8 Original | 8 To Date | 10 Est Final

2021-06-15:

  • On pause till Kafka 5.0 support is complete

2021-06-02: Updated target end date to 2021-06-25

  • CRUD changes in review. First round of change requests up
  • Currently working on cursors, timeouts and gridfs
  • Ross is mostly OOO this week since he is moving

2021-05-18: Maintaining target end date of 2021-05-28

  • CRUD changes in review
  • Currently working on cursors, timeouts and gridfs
  • Ross also worked on answering some user questions on Spark

2021-05-04: Updated target end date to 2021-05-28

  • Continuing work on the integration with operation layer
  • Close to wrapping up the CRUD integration
  • Server selection up next
  • Ross mentioned that the impl. touches a lot of code and the code review process won't be quick so we've updated the end date accordingly

2021-04-20: Maintaining target end date of 2021-05-12

  • No new updates since last time. Still working on the operations layer and CRUD integration
  • Ross was OOO last to last week and was Skunkking last week
  • He is also working on 2 HELP tickets atm

2021-04-06: Maintaining target end date of 2021-05-12

  • Currently working on updating existing timeouts according to the crud spec changes
  • Ross is OOO this week

2021-03-23: Setting initial target end date to 2021-05-12

  • Adding timeoutMS to settings in code review
  • Currently working on updating existing timeouts according to the crud spec changes


 Description   
Useful Info

Summary

Allow users to configure the timeout on operations by using a single timeout setting.

Motivation

Users have an array of options governing timeouts:
Driver timeouts: Server selection timeout, socket write timeout, socket read timeout, socket connect timeout
Server timeouts: maxTimeMS, maxAwaitTimeMS, wTimeout.
Users are often times unaware of the existence of all these settings and the effect they have on the timeout behavior of the driver and server. Due to this lack of awareness and understanding users often leave these settings at their defaults which is not necessarily what they desire in their timeout behaviors. Furthermore, timeout interaction with retryable writes compounds the situation. The timeout settings do not provide any clarity or reassurance of how long a user will wait for any given write or read.

We should also determine if the desired behavior should be, retry as many times as possible within the defined time period.

Cast of Characters

Lead: Jeff Yemin
Author: Divjot Arora
POCs: Java, C, Go, Swift
Product Owner:
 

Documentation

Scope Document


JQL search link to all sub tasks



 Comments   
Comment by PM Bot [ 04/Feb/22 ]

If you are not logged in, you can view the tickets in this epic by following this link.

Generated at Thu Feb 08 09:00:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.