You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Alex Parvulescu (JIRA)" <ji...@apache.org> on 2016/02/01 12:05:39 UTC

[jira] [Comment Edited] (OAK-3961) Cold Standby revisit timeout setup

    [ https://issues.apache.org/jira/browse/OAK-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15125328#comment-15125328 ] 

Alex Parvulescu edited comment on OAK-3961 at 2/1/16 11:04 AM:
---------------------------------------------------------------

* -removed the global timeouts-, refactored all the test with a more aggressive timeout value [r1727813|http://svn.apache.org/viewvc?rev=1727813&view=rev]
* fixed a tiny compilation issue in oak-run with [r1727816|http://svn.apache.org/viewvc?rev=1727816&view=rev]
* had to read the global timeout handler (it was the only way to control the timeout on the initial connection to a server that has a blacklist, otherwise it would hang), but to keep things consistent I'm removing it once the initial sync conversation happens (the timeout handler will only control the initial head request), this allowed for enabling of the _FailoverIPRangeTest_ test [1727831|http://svn.apache.org/viewvc?rev=1727831&view=rev], [1727832|http://svn.apache.org/viewvc?rev=1727832&view=rev]

I'm now curious to see if this is too low for the CI infra. I went up to 300 ms, then 500 ms. I need to keep an eye on this, I'm not sure timeouts are the only issue though.


was (Author: alex.parvulescu):
* -removed the global timeouts-, refactored all the test with a more aggressive timeout value [r1727813|http://svn.apache.org/viewvc?rev=1727813&view=rev]
* fixed a tiny compilation issue in oak-run with [r1727816|http://svn.apache.org/viewvc?rev=1727816&view=rev]
* had to read the global timeout handler (it was the only way to control the timeout on the initial connection to a server that has a blacklist, otherwise it would hang), but to keep things consistent I'm removing it once the initial sync conversation happens (the timeout handler will only control the initial head request), this allowed for enabling of the _FailoverIPRangeTest_ test [1727831|http://svn.apache.org/viewvc?rev=1727831&view=rev], [1727832|http://svn.apache.org/viewvc?rev=1727832&view=rev]

I'm now curious to see if this is too low for the CI infra.

> Cold Standby revisit timeout setup
> ----------------------------------
>
>                 Key: OAK-3961
>                 URL: https://issues.apache.org/jira/browse/OAK-3961
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: tarmk-standby
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>              Labels: candidate_oak_1_2
>
> The timeout settings are too large and inefficient, making all the tests very slow. On top of this the current timeout if being enforced in 2 places, which turns out it doesn't play too well with the sync mechanism:
> * one is via the _ReadTimeoutHandler_ in the _StandbyClient_
> * second is in the _SegmentLoaderHandler_
> as it turns out the first one is a global kill switch, and it will fail any transaction larger than the set value (_all_ of the sync cycle), which is not what I meant to do with it, so I'll remove it and only leave the second one, which is a timeout per request (segment or binary).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)