ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorenzo Bolzani <l.bolz...@gmail.com>
Subject Re: Duplicate channel id: concurrency problem?
Date Thu, 18 Aug 2011 15:53:13 GMT
2011/8/18 arunjolly <jollyarun@gmail.com>

>
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message