Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
client side OOME with Async operations 3.8-SNAPSHOT #9665
while making async operations test, I got a client side GC Overhead limit exceeded, OOME http://220.127.116.11/~jenkins/workspace/temp/HzClient460HZ-hprof.zip
One instance of "com.hazelcast.util.executor.LoggingScheduledExecutor" loaded by "sun.misc.Launcher$AppClassLoader @ 0xe6fae438" occupies 327,143,344 (97.65%) bytes. The memory is accumulated in one instance of "java.util.concurrent.RunnableScheduledFuture" loaded by "".`
so it looks like in hat master, we have a client side OOME,
member side seams ok.
i can only get this result with a full on 2000 client 3 member,
async near cache test result in client size hprof. and hs_err jvm crash and core
One instance of "com.hazelcast.util.executor.LoggingScheduledExecutor" loaded by "sun.misc.Launcher$AppClassLoader @ 0xe72530d8" occupies 244,743,832 (58.78%) bytes. The memory is accumulated in one instance of "java.util.concurrent.RunnableScheduledFuture" loaded by "".
200 instances of "com.hazelcast.internal.nearcache.impl.invalidation.RepairingHandler", loaded by "sun.misc.Launcher$AppClassLoader @ 0xe72530d8" occupy 54,078,400 (12.99%) bytes.
CallIdSequence will be completed to accept next invocation only when the callbacks running on internal executors are completed. A second change made to achieve back pressure safely. If response is already available when andThen is called with an internal callback. Then internal callback runs on calling thread instead of executor. Since it is already not permitted to do any blocking call in internal threads, this will achieve a natural backpressure. fixes hazelcast#9665 fixes hazelcast#8568