I think we can cache the ScriptEngine as a thread local variable, and we need to find a way to clean up these variables when the camel route is shutdown. So I just fill a JIRA[1] for it.
[1] https://issues.apache.org/jira/browse/CAMEL-6559 -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Thursday, July 18, 2013 at 3:01 PM, Willem jiang wrote: > The ScriptEngine evaluate method is not thread safe, I think you can use seda > component to cache the request in the queue, then using one consumer to > processing the groovy script. > > > -- > Willem Jiang > > Red Hat, Inc. > FuseSource is now part of Red Hat > Web: http://www.fusesource.com | http://www.redhat.com > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) > (English) > http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > > > > > On Thursday, July 18, 2013 at 1:21 AM, apatel wrote: > > > In below code why method is synchronized? This prevents camel groovy script > > for High Concurrency. > > > > > > protected synchronized Object evaluateScript(Exchange exchange) { > > try { > > getScriptContext(); > > populateBindings(getEngine(), exchange); > > addScriptEngineArguments(getEngine(), exchange); > > Object result = runScript(exchange); > > LOG.debug("The script evaluation result is: {}", result); > > return result; > > } catch (ScriptException e) { > > if (LOG.isDebugEnabled()) { > > LOG.debug("Script evaluation failed: " + e.getMessage(), e); > > } > > throw createScriptEvaluationException(e.getCause()); > > } catch (IOException e) { > > throw createScriptEvaluationException(e); > > } > > } > > > > > > > > > > I've below two routes. When i tested this route with 1 tps it returns > > responses in avg 1005 ms but when i tested same route with 5tps it returns > > responses in avg 8005 ms. My goal is tuning this routes for High > > Concurrency. > > > > <route xmlns="http://camel.apache.org/schema/spring"; trace="true"> > > <from uri="restlet:/test/v1.0/testGroovyWait"/> > > <to uri="direct:test.directGroovyWait.v1.0"/> > > </route> > > > > <route xmlns="http://camel.apache.org/schema/spring"; > > errorHandlerRef="noErrorHandler"> > > > > <from uri="direct:test.directGroovyWait.v1.0"/> > > <setHeader headerName="foo"> > > <groovy> > > Thread.sleep(1000) > > return "OK" > > </groovy> > > </setHeader> > > > > <setBody> > > <header>foo</header> > > </setBody> > > > > </route> > > > > > > I think we've found the root cause of our groovy performance problem. I did > > a little testing this morning and found that a single thread test with the > > route that waits 1 second had an average response time of about 1005 > > milliseconds. When I took this to 5 threads the average response time went > > up to 4389. When I went to 10 threads the average went to 9169. This is all > > without any pauses in the script so each thread is hitting the server as > > soon as the result returns. > > > > Here's the pattern of response times at the beginning of the 10 thread test: > > > > 1004, 1101, 2201, 3303, 4403, 5504, 6605, 7705, 8806, 9908, 2000, 4001, > > 6001, 8002, 10003, 12003, 14005, 16005, 18006 > > > > Interestingly the 3rd thread took 2.2 seconds, the 4th thread took 3.3 > > seconds, the 5th thread 5.5 seconds and so on. This clearly pointed to some > > sort of semaphore or single resource that each thread was waiting for in > > turn. > > > > I took a look at the active threads using console. Here's where most of the > > worker threads (http-bio-8080-exec-<n>) were waiting: > > > > Name: http-bio-8080-exec-3 > > State: BLOCKED on org.apache.camel.builder.script.ScriptBuilder@12349d8 > > owned by: http-bio-8080-exec-6 > > Total blocked: 99 Total waited: 271 > > > > Stack trace: > > org.apache.camel.builder.script.ScriptBuilder.evaluateScript(ScriptBuilder.java:338) > > org.apache.camel.builder.script.ScriptBuilder.evaluate(ScriptBuilder.java:92) > > org.apache.camel.builder.script.ScriptBuilder.evaluate(ScriptBuilder.java:96) > > org.apache.camel.builder.ProcessorBuilder$4.process(ProcessorBuilder.java:103) > > org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) > > org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) > > > > > > from > > --Doug > > > > > > > > > > > > > > > > > > > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/Groovy-script-synchronized-issue-with-2-10-x-and-2-11-x-prevents-camel-groovy-script-for-High-Concurc-tp5735815.html > > Sent from the Camel - Users mailing list archive at Nabble.com > > (http://Nabble.com). >
