Concurrent Versions System - Patches: patch #4992, Client/Server connection timeout
You are not allowed to post comments on this tracker with your current authentication level.
patch #4992: Client/Server connection timeout
Submitter: | Derek Robert Price <dprice> | ||
Submitted: | Fri 24 Mar 2006 07:50:47 PM UTC | ||
Category: | Feature (patch attached) | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Fixed Release: | None | Fixed Feature Release: | None |
( Jump to the original submission )
Wed 05 Apr 2006 02:46:18 PM UTC, comment #6: |
Derek Robert Price <dprice>![]() |
Wed 05 Apr 2006 02:22:37 PM UTC, comment #5: Larry Jones writes:
|
Derek Robert Price <dprice>![]() |
Tue 28 Mar 2006 03:33:09 PM UTC, comment #4: I've committed this patch plus doc and a test, with a default timeout value of 0. I'm not closing this issue until we settle the default timeout discussion. |
Derek Robert Price <dprice>![]() |
Tue 28 Mar 2006 01:04:37 PM UTC, comment #3: It's possible CVSLCKSLEEP + something bigger than 1 might make sense with a heavily loaded server. Perhaps with a commit, which I dare say might have to wait for a lock, the check pass might run for longer than a second before getting to the second (commit) pass and returning any data, causing an undesirable timeout with this default.
|
Derek Robert Price <dprice>![]() |
Tue 28 Mar 2006 12:26:13 AM UTC, comment #2: The present default in main.c:
|
Mark D. Baushke <mdb>![]() |
Mon 27 Mar 2006 01:32:17 PM UTC, comment #1: I'm attaching a revised patch based on private review by Mark Baushke and the subsequent discussion.
|
Derek Robert Price <dprice>![]() |
Fri 24 Mar 2006 07:50:47 PM UTC, original submission:
Any thoughts on the attached patch to feature, other than the fact that I haven't added test cases and doc yet? It adds a connection timeout to the client or server via a command line option.
|
Derek Robert Price <dprice>![]() |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Since very large timeouts may make sense, I've committed a change to accept `d', `h', `m', & `s' units (days, hours, minuts, & seconds, respectively) as arguments to --timeout and updated the documentation accordingly, including a warning about short server timeouts.
What about a default like 24h, or even 30m? That seems like plenty of time to leave a connection open and there shouldn't be much more CPU cost to run this code.