[
https://issues.apache.org/jira/browse/CASSANDRA-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-9292:
---------------------------------------
Fix Version/s: 4.x
Status: Patch Available (was: Open)
https://github.com/krummas/cassandra/commits/marcuse/9292
https://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-9292-dtest/
https://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-9292-testall/
Simply removes the synchronized and lowers the timeout. Reason the timeout was
that big was that we used to select sstables to repair in the prepare step
[~bdeggleston] can you review?
> ParentRepairSession potentially block ANTI_ENTROPY stage
> --------------------------------------------------------
>
> Key: CASSANDRA-9292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9292
> Project: Cassandra
> Issue Type: Bug
> Reporter: Yuki Morishita
> Assignee: Marcus Eriksson
> Priority: Minor
> Fix For: 4.x
>
>
> Follow up from CASSANDRA-9151,
> {quote}
> potentially block this stage again since many methods are synchronized in
> ActiveRepairService.
> Methods prepareForRepair(could block for 1 hour for prepare message response)
> and finishParentSession(this one block for anticompaction to finish) are
> synchronized and could hold on to the lock for a long time.
> In RepairMessageVerbHandler.doVerb, if there is an exception for another
> repair, removeParentRepairSession(also synchronized) will block.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
