You wrote that use ode 1.3.3 or ode 1.3.5?
ODE 1.3.4 or 1.3.3 (I don't remember which one) had a general performance issue
which was solved definitely in ode 1.3.5.
Secondly use database in-memory mode as it is a bootleneck for the high speed
in-memory processes.
Add to jndi.xml entry:
<entry key="java:comp/env/jdbc/ode">
<bean class="org.apache.derby.jdbc.EmbeddedDataSource">
<property name="databaseName" value="memory:ODEDB"/>
<property name="connectionAttributes"
value=";restoreFrom=data/smx/components/OdeBpelEngine/version_1/jpadb"/>
<property name="user" value="sa"/>
</bean>
</entry>
And change ode.properties:
ode-jbi.db.mode=EXTERNAL
ode-jbi.db.ext.dataSource=java:comp/env/jdbc/ode
Then you can try to tweek other properties:
ode-jbi.threads.pool.size=120
# To mitigate ODE-943
ode.scheduler.queueLength=2147483647
ode.scheduler.transactionsPerSecond=1000
--
Regards,
Mateusz Nowakowski
-----Original Message-----
From: arunjolly [mailto:[email protected]]
Sent: Thursday, January 24, 2013 17:23
To: [email protected]
Subject: Apache ODE 1.3.5 - In Memory Execution - How stable ?
Hi,
We use apache ode 1.3.3 inside Servicemix 3.3.2 for implementing our workflows.
When the load increases (ie number of flow invocations per unit time ), ode
freezes, stops processing new requests and hangs. Usullay, we solve the issue
by doing a Servicemix restart after a cleanup of the 'data'
folder.
Initially, i thought that this was a thread problem ( lack of threads for ode
to use ). After increasing the 'thread pool size' in ode-jbi.properties, this
problem got addressed to an extend. But still, under heavy load, ode continues
to hang.
Further investigation, with additional logging revealed that under heavy load,
ode is unable to get enough connections to the DB (NoManagedConnectionException
) to persist its state. Our ode persistence configuration is INTERNAL (refer to
ode-jbi.db.mode=INTERNAL ) where the connection pool is maintained by the
container/runtime itself. Efforts to migrate it to a EXTERNAL jndi datasource
configuration ( where we can configure the connection pool parameters ) has not
yet borne fruit ( Thanks to my inability to comprehend the zillion errors that
keep cropping up at each stage :( :) )
So i tried the other available option, 'In-Memory execution' of my processes.
This works fine in a 'test setup' and it no longer throws the
'NoManageConnectionException' under simulated load.
But i have a few concerns about moving this to PROD. How different is
In-Memory execution different from 'persisted' execution ? How much more memory
will this consume ? Will this affect the reliability of my PROD setup by
causing 'OutOfMemoryOutages'.
We have about 10 deployed bpel processes. And the load (no. of requests
)...well it is usually minimal, but sometimes spikes up ( that's where i need
my processes to run really fast but without causing any OutOfMemory PROD
outages...hopefully :D :) :P )
Need your thoughts, suggestions and advice on this.
Thanks in advance,
Arun
--
View this message in context:
http://old.nabble.com/Apache-ODE-1.3.5---In-Memory-Execution---How-stable---tp34941139p34941139.html
Sent from the Apache Ode User mailing list archive at Nabble.com.
