[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1982: -------------------------------- There is one big problem: if we have requests {noformat} | R1 | | R2 | R3 | R4 | ... | R999 | R1000 | {noformat} , and responses for {{R2}} - {{R999}} have been received, then the {{low}} pointer won't be advanced until {{R1}} has been received! This means that the table is going to grow, possibly infinitely... The problem occurred in UPerf where starting the benchmark on all cluster nodes involves an initial _blocking_ RPC (non-blocking RPCs don't use {{RequestTable}}), e.g. {{R1}} starts the test on all nodes and waits until it has results from all nodes. Although RequestTables can be compacted, this may use too much memory. E.g. one could come up with a case where an RPC sleeps for 30 minutes (unlikely, but we can't control this!), which prevents the {{low}} point from advancing until the RPC returned, and increase the size of the underlying array in {{RequestTable}}. h3. Solutions * Make users aware of this? Ie. don't use blocking RPCs that don't return for a long time? * Offer both the good old hashmap *and* a {{RequestTable}}? Configure {{RpcDispatcher}} / {{MessageDispatcher}} to switch between the impls? Using {{RequestTable}} reduces memory usage quite a bit and made {{UPerf}} faster, so I'd hate to trash this idea! :-) -- This message was sent by Atlassian JIRA (v6.4.11#64026)