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

ASF subversion and git services commented on SOLR-13054:
--------------------------------------------------------

Commit c5426ecd1807ab75f86b5932b64944fc7df85718 in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c5426ec ]

SOLR-13054: rewrite TriggerSetPropertiesIntegrationTest

test no longer depends on changing static non-final non-volatile variables used 
by multiple threads

test also no longer depends on arbitrary sleep calls, instead threads 
await/poll on concurrent signaling objects/queues

(cherry picked from commit 3147c131e0ce997259f7bcf31e655d43dd99ef59)


> TriggerSetPropertiesIntegrationTest cleanup
> -------------------------------------------
>
>                 Key: SOLR-13054
>                 URL: https://issues.apache.org/jira/browse/SOLR-13054
>             Project: Solr
>          Issue Type: Test
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>            Priority: Major
>         Attachments: SOLR-13054.patch
>
>
> While investigating some odd jenkins failures from 
> TriggerSetPropertiesIntegrationTest, I'm left with the conclusion that as 
> implemented, the test was susceptible to order of operation bugs due to how 
> the multiple threads would access a static _non-final *non-volatile*_ 
> CountdownLatch for keeping track of when/if anough iterations had past -- 
> based on the (limited) logging that was being produced, it seemed like 
> thescheduled threads were picing up the "first" {{new CountdownLatch(1)}} 
> assigned to that variable, even though the test expected it to use the second 
> {{new CountdownLatch(2)}}
> It's possible that just marking this variable {{volatile}} would have 
> prevented these failures -- but as designed the test was also very dependent 
> on arbitrary {{sleep()}} delays, so instead i've redisgned it to use 
> differnet signaling mechanisms using {{await()}} calls on concurrent signal 
> structures.
> Opening this issue to track these test improvements and any subsequent tweaks 
> needed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to