ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject Re: Re: TransactionManager error when invoking multiple instances on two ODE engines
Date Thu, 13 Mar 2014 11:23:10 GMT
Hi Vito,

it doesn't matter if they share the same JVM but if they share the same
data in the database, then you will run into trouble unless you solve some
issues needed for clustering. The background is the following: If ODE
receives a request, it loads the instance, determines the next steps and
adds a new entry to the scheduler table for tasks that requires heavier
work. In a cluster you need to make sure that this scheduled job is
assigned to a single node and not taken up by all nodes. The scheduler is
ready to do that, but the missing piece is the cluster management that
assigns IDs to nodes etc. This can be implemented with hazelcast for
instance.

As a side note: When you use an external database, it is important that you
have properly configured the transactions manager, either by using
https://github.com/vanto/apache-ode-tomcat-bundle or by following the
Sathwik's instructions at
http://sathwikbp.blogspot.de/2013/09/apache-ode-on-tomcat-7-with-bitronix.html,
this could help as well.

HTH,
  Tammo


On Wed, Mar 12, 2014 at 2:49 AM, Vito <testforvln@163.com> wrote:

> Hi Tammo,
>
> Yes, both instances are nearly the same except for their different
> deployment port number, because they need to be deployed in the two ODE of
> different ports.
> Do you mean that they share the same jvm and database instance? It can
> really cause some problem.
> Actually I'm doing some work trying to implement simple load balance
> between different ODE instances, but it's just a external implementation
> without using any features of ODE cluster, which I'm not familiar with.
>
>
> Best,
> Vito
>
>
> At 2014-03-11 20:35:29,"Tammo van Lessen" <tvanlessen@gmail.com> wrote:
> >Hi Vito,
> >
> >do both instances share the same database schema?
> >
> >ODE is currently not able to run in a cluster. Actually it is in general
> >ready for clustering but two pieces of glue code are missing. 1) the load
> >balance, 2) the master slave management that is needed for the scheduler
> >and the process store. Thus, without a not-too-small amount of developer
> >work its currently not possible to setup a cluster based on open source
> >ODE. Also, ODE then assumes that the process definitions are the same
> >across all instances within the cluster.
> >
> >Or did I get your question wrong?
> >
> >Tammo
> >
> >
> >On Tue, Mar 11, 2014 at 9:44 AM, Vito <testforvln@163.com> wrote:
> >
> >>  Hi all, I'm trying to invoke multiple instances on two ODE engines.
> >> I deployed the two engines in two tomcat servers of different ports in
> the
> >> same computer. Then invoked 15 same process instances on each ODE
> engine,
> >> and the two process definitions for the two engines are not the same.
> When
> >> I invoked them all, the first engine went well, but the instances on the
> >> second engine sometimes worked well, sometimes it threw exception like
> >> below:
> >>
> >> 16:28:01,939 WARN  [Transaction] Unexpected exception from
> >> beforeCompletion; transaction will roll back
> >> <openjpa-1.2.1-r752877:753278 nonfatal user error>
> >> org.apache.openjpa.persistence.InvalidStateException: Attempt to commit
> a
> >> null javax.transaction.Transaction.  Some application servers set the
> >> transaction to null if a rollback occurs.
> >>     at
> >>
> org.apache.openjpa.kernel.BrokerImpl.setRollbackOnlyInternal(BrokerImpl.java:1490)
> >>     at
> >>
> org.apache.openjpa.kernel.BrokerImpl.setRollbackOnly(BrokerImpl.java:1476)
> >>     at
> >>
> org.apache.openjpa.kernel.DelegatingBroker.setRollbackOnly(DelegatingBroker.java:925)
> >>     at
> >>
> org.apache.openjpa.persistence.EntityManagerImpl.setRollbackOnly(EntityManagerImpl.java:560)
> >>     at
> >>
> org.apache.openjpa.persistence.PersistenceExceptions$2.translate(PersistenceExceptions.java:71)
> >>     at
> >>
> org.apache.openjpa.kernel.BrokerImpl.translateManagedCompletionException(BrokerImpl.java:1896)
> >>     at
> >>
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1830)
> >>     at
> >>
> org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514)
> >>     at
> >>
> org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:498)
> >>     at
> >>
> org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
> >>     at
> >>
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257)
> >>     at
> >>
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:238)
> >>     at
> >>
> org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:291)
> >>     at
> >>
> org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:239)
> >>     at
> >>
> org.apache.ode.scheduler.simple.SimpleScheduler$RunJob.call(SimpleScheduler.java:512)
> >>     at
> >>
> org.apache.ode.scheduler.simple.SimpleScheduler$RunJob.call(SimpleScheduler.java:496)
> >>     at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> >>     at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> >>     at
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> >>     at
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> >>     at java.lang.Thread.run(Thread.java:662)
> >>
> >> BTW after the error the instances can still go on to the normal end.
> Maybe
> >> the rollback saved the instance.
> >> It seems that something went wrong with the transaction manager. Could
> you
> >> help me figure out how this error came out?
> >> Best,
> >> Vito
> >>
> >
> >
> >
> >--
> >Tammo van Lessen - http://www.taval.de
>



-- 
Tammo van Lessen - http://www.taval.de

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