[ https://jira.jboss.org/jira/browse/JGRP-1097?page=com.atlassian.jira.plug... ] Seamus Donohue updated JGRP-1097: --------------------------------- Description: using latest sourceforge cvs repository snapshot (from logger 'INFO: JGroups version: 2.8.0.CR6'). while this is not causing any noticicable failures in our testing I noticed that the connected and closed flags are set in synchronized but read in unsynchronized methods - patch file attached. *note* also attached in patch : made additional_data a concurrent hashmap: protected final Map<String,Object> additional_data=new ConcurrentHashMap<String,Object>(); as I think concurrently executing send(Message msg) operations which call ' down(new Event(Event.MSG, msg));' which in turn calls additional_data.putAll(m) will result in inconsistent hashmap state if putAll operations are concurrent but as I am unfamiliar with the code I am not sure what is the best way to address this. was: using latest sourceforge cvs repository snapshot (from logger 'INFO: JGroups version: 2.8.0.CR6'). connected and closed flags are set in synchronized but read in unsynchronized methods - patch file attached. *note* also attached in patch : made additional_data a concurrent hashmap: protected final Map<String,Object> additional_data=new ConcurrentHashMap<String,Object>(); as I think concurrently executing send(Message msg) operations which call ' down(new Event(Event.MSG, msg));' which in turn calls additional_data.putAll(m) will result in inconsistent hashmap state if putAll operations are concurrent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-1097?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1097: -------------------------------- Applied the patch for closed and connected, but left additional_data as a HashMap; access to this hashmap is never concurrent and only at channel config time. In 3.0, additional_data will be removed anyway. thx ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-1097?page=com.atlassian.jira.plug... ] Seamus Donohue commented on JGRP-1097: -------------------------------------- ok I see how the additional_data is used -thanks for clarification... BTW I just happened to be working on options and views after creating this JIRA - should the following also be volatile ? receive_blocks,receive_local_msgs, my_view- as read/modified by Object up(Event evt) using protocol stack threads and set/read by JMX/pub methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira