[jboss-jira] [JBoss JIRA] Commented: (JGRP-806) Message: investigate making the overhead for headers smaller

[ https://jira.jboss.org/jira/browse/JGRP-806?page=com.atlassian.jira.plugi... ] Michal Frajt commented on JGRP-806: ----------------------------------- The current Message (1.84) is not using the ConcurrentHashMap for the headers anymore. The CCHM is used for the canonical adrresses which is a class static instance. The message headers are currently handled using the default java HashMap class. It might be a good solution if there are many headers attached to a common message object. As far as I could see (debug) from our first test application there was just one header attached to messages recevied from the defalt channel (multicast-localhost). How many headers are added by the protocol stacks to sent/received messages? The header name/value pair could be just simply stored in an Object array and iterated for every header put and every header get call. The array would be extended when there are more headers than preallocated size (parameter) required. The second issue is with the synchronization object currently used for the headers access. The ReentrantReadWriteLock is pretty expensive class to be created for every message sent or received by the protocol stacks. Is there really a situation that the same message object is modified (putHeader) and processed (getHeader) from multiple threads? The message is either sent (down the stack) or received (up the stack) by a single thread execution. I think that an object monitor should be considered for the headers synchronization . # # EXAMPLE # private final Object headersMonitor = new Object(); private Object[] headers = new Object [DEF_HEADERS << 1]; ... public Header getHeader(String key) { synchronized(this.headersMonitor ) { for(int i = 0; i < header.length; i+=2) { if(this.headers[i] == null) { return null; } else if(this.headers[i].equals(key)) { return (Header) this.header[i + 1]; } } } return null; } ... -- 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