[ https://issues.jboss.org/browse/WFLY-5811?page=com.atlassian.jira.plugin.... ] Mathieu Lachance commented on WFLY-5811: ---------------------------------------- Hi [~pferraro], we are currently doing performance testing around session replication (REPL_ASYNC) with Wildfly 8.2.1.Final and I was wondering if what we discovered could be related to this issue. One thing we do not understand is, even if we are using BATCH we are seeing in the TransactionCoordinator::commit method, multiple WriteCommand for the same key, i.e. for each [non-immutable] session get/setAttribute, one PutKeyValueCommand followed by n amount of ReplaceCommand. Shouldn't in batch mode everything be collapsed into one single PutKeyValueCommand? In Wildfly 10.0.0.Final, there's one notable difference, instead of having one PutKeyValueCommand followed by n ReplaceCommand we are only seeing multiple PutKeyValueCommand. But again, shouldn't that be all collapsed into one single PutKeyValueCommand? Not collapsing the changes will for sure increase the amount of WriteCommand sent on the wire for basically nothing (?). Sure we could enable JGroups compression in the protocol stack, though, I feel this is more a workaround than a potential fix. I did not have a deep comparison yet with EAP, though, it looks like the session storage strategy have changed between EAP and Wildfly. Could you confirm? Could it be that in EAP, in the FineSessionAttributeStorage, the sessionData.getModifiedSessionAttributes() was already collapsing everything when trying to replicate attributes? Either case, could you share more information about your performance testing scenarios. I'd like to see if we are potentially affected by the same issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026)