[jboss-jira] [JBoss JIRA] Resolved: (JGRP-805) Message getHeaders not protected from concurrent modification

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/jira/browse/JGRP-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-805.
---------------------------

    Resolution: Done


Fixed in head and 2.6 by
- adding synchronization to gteHeaders()
- returning a copy of headers rather than an immutable ref to a mutable data structure
Overhead issues are discussed in JGRP-806

> Message getHeaders not protected from concurrent modification
> -------------------------------------------------------------
>
>                 Key: JGRP-805
>                 URL: https://jira.jboss.org/jira/browse/JGRP-805
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>         Environment: 2.6.3.GA
>            Reporter: Michal Frajt
>            Assignee: Bela Ban
>             Fix For: 2.6.4, 2.7
>
>
> We have just downloaded the latest JGroups 2.6.3.GA version for some initial multicast testing. There is no expirience with the API on our side. The initial review of the Message class shows us huge memory requirements of each message instance. The HashMap for headers and the ReentrantReadWriteLock for headers access seems to be a bit to much overhead for messages with the data (buf) lenght of few bytes. 
> Despite using the heavy RRWLock there is an unprotected read access to the headers map possible. The method getHeaders returns the headers as unmodifiableMap instead of a copy created within the read lock. An iteration over the returned unmodifiableMap might throw ConcurrentModificationException as the same headers map object might be modified using the putHeader method.

-- 
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