[
http://jira.jboss.com/jira/browse/JGRP-495?page=comments#action_12361168 ]
Bela Ban commented on JGRP-495:
-------------------------------
oob_loopback_msgs seems to have been the culprit; we added messages (even regular ones),
but only removed OOB messages, causing this hashmap to grow indefinitely !
Testing with 3 million messages each (2 nodes) works... will need to do more testing, with
larger message sets.
Result for 2 nodes, each sending 3 million 1K messages: 17800 messages/sec:
-- results:
192.168.5.2:3464:
num_msgs_expected=6000000, num_msgs_received=6000000 (loss rate=0.0%), received=6GB,
time=335687ms, msgs/sec=17873.79, throughput=17.87MB
192.168.5.2:3474 (myself):
num_msgs_expected=6000000, num_msgs_received=6000000 (loss rate=0.0%), received=6GB,
time=335969ms, msgs/sec=17858.79, throughput=17.86MB
combined: 17866.29 msgs/sec averaged over all receivers (throughput=17.87MB/sec)
Memory leak in NAKACK
---------------------
Key: JGRP-495
URL:
http://jira.jboss.com/jira/browse/JGRP-495
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Blocker
Fix For: 2.5
Probably due to the changes introduced in NAKACK/NakReceiverWindow
(
http://jira.jboss.com/jira/browse/JGRP-281).
To reproduce, run perf.Test on 2 nodes with 1 million 1K messages each. JProfiler shows
that we are leaking Map.Entry instances in NAKACK. They seem to accumulate in xmit_table.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira