2011/8/18 arunjolly <[email protected]> > > Lorenzo, > > Thanks a lot for your reply. A lot of things makes a lot of sense now. >
Hi Arun, I'm not a servicexmix or ode expert, I'm just doing a lot of debugging in these days. So double check what I tell with docs or other sources. > I read the link about thread configuration. Its says that, by default, all > the servicemix components inherit the 'thread configuration properties' of > org.apache.servicemix.executors.ExecutorFactory specified in > servicemix.xml > in the conf directory of servicemix. > Yes, actual values are taken from the servicemix.properties file. > But if you look at it, the ode-bpel engine ( the zip file ) contains a > properties file - ode-jbi.properties which has a attribute called > ode-jbi.threads.pool.size. Does this over ride the default properties set > in > the servicemix.xml file or will the bpel engine continue to inherit the > thread properties specified in servicemix.xml file ? > Servicemix creates several ThreadPoolExecutor (TPE) for different components. For example the TPE for cxf-se is called flow.seda.servicemix-cxf-se and thread inside this TPE are called, for example pool-flow.seda.servicemix-cxf-se-thread-16 Then there are some "anonymous" TPE that also follow the "pool-" + name + "thread" + index naming convention but the "name" part is just a counter. Ode uses one of these TPE. In my setup the number is 6 (e.g. pool-6-thread-12), but I think it depends on the actual deployment/startup order of the components (you can find it out by placing a breakpoint inside OdeConsumer.invokePartner or using a "strange" number for the pool size and, after a few bpel executions, look for a pool of that size with jconsole). The sizing of this TPE can be configured using the ode-jbi.threads.pool.size property, I'm using this to 20. I suppose you can also configure this TPE inside the servicemix.xml file but being the exact number variable this can be tricky. > In my case, the servicemix.xml file contains the following configuration > > <sm:executorFactory> > <bean > class="org.apache.servicemix.executors.impl.ExecutorFactoryImpl"> > <property name="defaultConfig"> > <bean > class="org.apache.servicemix.executors.impl.ExecutorConfig"> > <property name="corePoolSize" value="100"/> > <property name="maximumPoolSize" value="100"/> > <property name="queueSize" value="10000"/> > </bean> > </property> > </bean> > </sm:executorFactory> > > and the ode-jbi.properties contains the following configuration > ode-jbi.threads.pool.size=1 > > It will great if you can tell me where exactly and how exactly i need to > configure the thread properties for the ODE component of servicemix. > It depends of, and if, you have some TPE that consumes all of his threads. The easiest way to check this is by inspecting the thread dump of all the threads using the jconsole. If you find that all the thread from a TPE are blocked on the Object.wait(long) method probably you have to change the configuration for that specific TPE. > Also, the synchronous = false parameter, from an ode point of view, how > exactly do i set it ? > This parameter is for the cxfbc:consumer components, inside xbean.xml. I do not know if other components support this parameters. I also suppose it is advised only if you use the sendSync(exchange) call which could not be your case. > I forward JMS messages to the embedded activemq component inside > servicemix, > use the camel component to route these requests/messages to the BPEL > endpoints. That's a brief description of how my application works. > I suppose the BPEL invokes some webservices that could or could not be deployed the inside servicemix. AFAIK when bpel make a synchronous invocation of a WS the following happens: 1. one thread from the ode pool places a "invocation message" on the seda flow queue and goes on Object.wait 2. one thread is taken from the cxf pool, this dequeue the previous message and pass it to the actual WS 3. if this WS invokes synchronously invokes another WS of if the BPEL invokes multiple WS concurrently the cxf pool could be too small This was my case. Your case could also/instead be related to the JSM/ActiveMQ pool or the ODE pool, considering the size is 1. If you can easily reproduce the freeze you can try to set the global queueSize to zero and check if this "solves" the problem. If this works, you should then find the specific TPE, or TPEs, that needs this special value. I suppose the zero length queue is not a recommended settings so I'd try to use it only where required. I would also rise the ode-jbi.threads.pool.size to 20. What I wrote in my very first message about the possibility of the _objIdCounter being incorrectly updated was wrong: each thread has a separate "counter space" (if I understood it right this time...). A couple of other things I found out (not related to the previous problem). There is an "in memory" execution option for bpel processes that could make these a lot faster, see: http://ode.apache.org/creating-a-process.html Probably you should also disable the events generation that floods the ODE_EVENT table http://ode.apache.org/ode-execution-events.html Ode adds several rows to several tables on each execution: this is what happens with my bpel process ODE_MESSAGE 16 ODE_MESSAGE_EXCHANGE 8 ODE_MEX_PROP 22 ODE_PARTNER_LINK 6 ODE_PROCESS_INSTANCE 1 ODE_SCOPE 8 ODE_XML_DATA 14 If the process runs often this can quickly add up (instead ODE_JOB rows are deleted a few seconds after the job completes). Hope this helps Bye Lorenzo
