Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
In case of running our code on a virtual machine, we are getting following exception:
com.hazelcast.core.OperationTimeoutException: No response for 10000 ms.
In production it could take several hours until occurrence. So we are using .setProperty(PROP_OPERATION_CALL_TIMEOUT_MILLIS, '5000')
We put together some example code: gist
If we run this code on two dedicated (virtual) machines,
some log messages from our load tests:
The virtual machines are configured to have a single core. Running the tests on non virtual machines
Hours later i have to correct my self. With a reduced amount of threads, the problem still exists.
how easy is it for you (or for us) to reproduce this issue?
I'll run it on my local setup because this is a very important bug for us to resolve.
On Tue, Apr 8, 2014 at 1:53 PM, Mike Großmann email@example.com:
Hi Peter ..
i will try :)
Both nodes running on java 1.7 on Ubuntu Precise.
The following VM State is from the current test system (the problem already occurred)
Java HotSpot(TM) 64-Bit Server VM version 23.6-b04
1 day 6 hours 24 minutes
Process CPU time:ﾠ
7 hours 37 minutes
HotSpot 64-Bit Tiered Compilers
Total compile time:ﾠ
Total threads started:ﾠ
Current classes loaded:ﾠ
Total classes loaded:ﾠ
Total classes unloaded:ﾠ
Current heap size:ﾠ
Maximum heap size:ﾠ
Name = 'Copy', Collections = 34.385, Total time spent = 9 minutes
Name = 'MarkSweepCompact', Collections = 38, Total time spent = 23,722 seconds
Number of processors:ﾠ
Committed virtual memory:ﾠ
Total physical memory:ﾠ
Free physical memory:ﾠ
Total swap space:ﾠ
Free swap space:ﾠ
-Dspring.profiles.active=oracle,cluster -Djava.net.preferIPv4Stack=true -Djava.security.auth.login.config=UserManager.config -Djava.util.prefs.systemRoot=/home/ -Xmx2048M -Djava.security.egd=file:///dev/urandom -Duser.language=de
This is our configuration:
Could you run with something else than ubuntu? E.g. centos/rhel. My
On Tue, Apr 8, 2014 at 5:58 PM, Mike Großmann firstname.lastname@example.org:
Just to let you know
We see lots of these warnings
Running Hazelcast 3.2.1
According to our developers, it's hard to reproduce, and happens only after some time.
I am currently converting the groovy examples to java/maven, and I have some questions regarding your example code.
In the consume closure, you are polling the preProcessingQueue for an instance of Data.
(The remove call in the Produce has (obviously) no relevance for the consume closure, as the consumer is likely to poll AFTER the producer has called remove)
In effect, each loop in the consume closure adds the data twice to the queue without removing it.
Any input on this?
referenced this issue
Jul 21, 2014
This was referenced
Aug 14, 2014
There is still the other failure mode - probably related to congestion or
On Tue, Aug 26, 2014 at 10:13 AM, Peter Veentjer email@example.com
“Perfection is achieved, not when there is nothing more to add, but when