Hi Vito, Can you share ode-axis2.properties file from both the tomcat servers to understand your deployment.
regards, sathwik On Fri, Mar 14, 2014 at 7:38 AM, Vito <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 >
