[
https://issues.jboss.org/browse/JGRP-1871?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1871:
--------------------------------
If it's only {{up_prot}} and {{down_prot}}, then that's fine as they're mostly
read and only written at stack init time, so that's fast.
However, making other fields {{volatile}} can have a big impact on perf: the memory
barriers established by volatile fields potentially trigger a lot of cache line flushes
and (especially with false sharing) a lot of reloading. No problem if this is mostly
reads, but fields with a lot of writes might slow things down a lot.
Even worse: testing this might yield good perf on one architecture, but bad perf on
another; e.g. when cache line sizes differ.
Since 1998 the stack architecture has been the same and no-one has ever run into this
except WF...
NPEs due to non-volatile Protocol variables
-------------------------------------------
Key: JGRP-1871
URL:
https://issues.jboss.org/browse/JGRP-1871
Project: JGroups
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.4.5, 3.5
Reporter: Paul Ferraro
Assignee: Paul Ferraro
In WildFly a given channel is created in one thread, but is potentially started in a
different thread. Unfortunately, many of the protocol variables that are set during
Protocol.init() are non-volatile. This can cause unexpected behavior as seen in
WFLY-3727.
To ensure clean initialization for multi-threaded environments like WF, all non-final
variables within every JGroups' Protocol should be volatile.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)