[
https://issues.apache.org/jira/browse/GEODE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-3774:
------------------------------------
Description:
{{ServerConnectionFactory}} uses double-checked locking for loading the
services it depends on.
It's probably looking at where else we may use this idiom, as it's
fundamentally broken.
Marking the field that's locked this way {{volatile}} may not resolve the
issue, as the object itself could be read as uninitialized even if the field
(reference) isn't. I don't really know the JMM well enough to be sure that it's
broken, but that's a good sign that we shouldn't do it unless we really need to
for performance reasons (and even then...)
This may be best to resolve after GEODE-3751 and GEODE-3739 due to the changes
to loading those refactors will bring.
While we're at it, we should assert that there is only one client protocol
service, because we can't handle to and which one we choose is undefined.
was:
It's probably looking at where else we may use this idiom, as it's generally
broken.
This may be best to resolve after GEODE-3751 and GEODE-3739 due to the changes
to loading those refactors will bring.
> Remove double-checked Locking in New Client Protocol code
> ---------------------------------------------------------
>
> Key: GEODE-3774
> URL: https://issues.apache.org/jira/browse/GEODE-3774
> Project: Geode
> Issue Type: Bug
> Components: client/server
> Reporter: Galen O'Sullivan
>
> {{ServerConnectionFactory}} uses double-checked locking for loading the
> services it depends on.
> It's probably looking at where else we may use this idiom, as it's
> fundamentally broken.
> Marking the field that's locked this way {{volatile}} may not resolve the
> issue, as the object itself could be read as uninitialized even if the field
> (reference) isn't. I don't really know the JMM well enough to be sure that
> it's broken, but that's a good sign that we shouldn't do it unless we really
> need to for performance reasons (and even then...)
> This may be best to resolve after GEODE-3751 and GEODE-3739 due to the
> changes to loading those refactors will bring.
> While we're at it, we should assert that there is only one client protocol
> service, because we can't handle to and which one we choose is undefined.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
