ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vito <testfor...@163.com>
Subject Re:Re: Re: TransactionManager error when invoking multiple instances on two ODE engines
Date Fri, 14 Mar 2014 02:08:50 GMT
Hi Tammo,

Thank you for your explanation and advice. Actually I deployed the two ODE engines in two
tomcat servers of different ports. So if I want to invoke, for example, 15 instances in ode1
and 15 instances in ode2, the requests have their difference in the ports of their addresses.
The question is, in this circumstance, do the two ode engines share the same database instance
when they run in two tomcat servers? I use the internal jpa database.


Best,
Vito


At 2014-03-13 19:23:10,"Tammo van Lessen" <tvanlessen@gmail.com> wrote:
>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