[
https://issues.apache.org/jira/browse/CURATOR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844452#comment-17844452
]
Roelof Naude commented on CURATOR-705:
--------------------------------------
consider the attached patch. it effectively removes the initialised check:
{code:java}
initializedLatch.getCount() == 0{code}
running the test cases in TestServiceCache fails:
{code:java}
Run 1: TestServiceCache.testUpdate:233 expected: <thing> but was:
<changed>{code}
if running only testUpdate it succeeds.
is there some sort of race condition being triggered?
> ServiceCache::getInstances do not return any instances
> ------------------------------------------------------
>
> Key: CURATOR-705
> URL: https://issues.apache.org/jira/browse/CURATOR-705
> Project: Apache Curator
> Issue Type: Bug
> Components: General
> Affects Versions: 5.6.0
> Environment: linux, java 21
> Reporter: Roelof Naude
> Priority: Major
> Attachments: curator-x-discovery.patch
>
>
> we've run into an issue with service discovery after upgrading from 4.3.0 to
> 5.6.0.
> ServiceCache::getInstances do not return any instances of a service.
> restarting the back-end services do allow ServiceCache to detect the
> instance. have managed to simulate this scenario in the test cases.
>
> TestServiceCache::testInitialLoad was modified to register instance1 before
> the cache has been started. an assert immediately after cache.start detects
> the failure, ie:
> {code:java}
> assertEquals(1, cache.getInstances().size());{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
