jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Parvulescu (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-3961) Cold Standby revisit timeout setup
Date Mon, 01 Feb 2016 11:05:39 GMT

    [ 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)

Mime
View raw message