ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nowakowski, Mateusz" <Mateusz.Nowakow...@sabre.com>
Subject RE: Apache ODE 1.3.5 - In Memory Execution - How stable ?
Date Fri, 25 Jan 2013 06:48:05 GMT
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"/>

And change ode.properties:


Then you can try to tweek other properties:


# To mitigate ODE-943

Mateusz Nowakowski

-----Original Message-----
From: arunjolly [mailto:jollyarun@gmail.com] 
Sent: Thursday, January 24, 2013 17:23
To: user@ode.apache.org
Subject: Apache ODE 1.3.5 - In Memory Execution - How stable ?


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'

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

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

View raw message