0

On Mule 3.8 Standalone Runtime with Java 8, we are testing a Scatter Gather flow mainly with outbound HTTP calls.

When running concurrent calls by a load test script, some flows have an unexplainable 1 minute wait; we can't see any traces in logs (brought down to Debug) or any other cause in the ESB runtime. HTTP services themselves are fine - no latency from services end whatsoever (monitored separately).

Is there some sort of a checklist for looking into Mule configuration parameters when we run such a test? Any other verbose diagnostic flags we can turn on to see extended trace info?

Forrest Running
  • 103
  • 1
  • 1
  • 6
  • Do you have enough threads for handling the load you are using? – Ale Sequeira Sep 20 '16 at 20:35
  • Yeah, it wasn't a thread contention issue. When we analyzed stack traces extracted in periodic intervals, we identified a java.util.SecureRandom.generateSeed() stack recurring consistently but in RUNNING state; turns out that Secure Random on Linux systems might be really slow - as discussed in [this SO thread](http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom). Resorting to a slightly less secure /dev/urandom via -Djava.security.egd=file:/dev/./urandom solved our wait issue. – Forrest Running Oct 05 '16 at 12:58

0 Answers0