You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Da...@empolis.com on 2009/03/23 18:31:49 UTC
Problem with flow and extension activities
Hi all,
in the SMILA project we are using extension activities to execute java
code in BPEL. This works without any problems.
Now I tried to execute two extension activities concurrently within a
<flow> (see attachment). The execution still works, but the extension
activities are not executed concurrently but in sequence. I debugged and
found that the extension activities are executed by the same thread.
We currently use ODE 2.0.
Is there any error on my bpel workflow ? Or is there a ThreadPool that's
size needs to be increased ? Or some other configuration option ?
Thanks for your help!
Bye,
Daniel
Re: Problem with flow and extension activities
Posted by Rafal Rusin <ra...@gmail.com>.
As I know, ODE takes an instance lock for executing actions inside a
process. So this looks like something not to overcome easily.
2009/3/24 <Da...@empolis.com>:
> Hi all,
>
> the problem seems not to be related to extension activities only. I did a test invoking webservices:
>
> ...
> <flow>
> <invoke name="sayHi" partnerLink="HelloWorld"
> portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
> outputVariable="response">
> </invoke>
>
> <invoke name="sayHo" partnerLink="HelloWorld"
> portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
> outputVariable="response2">
> </invoke>
> </flow>
> ...
>
> The two invoke elements are executed in random order. However the second invoke call is not executed until the first invoke returns. It seems that the same Thread is used to execute the invoke calls. We use the integrated SimpleScheduler.
>
> Anyone any ideas what's going wrong here ?
>
> Bye,
> Daniel
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
>> Gesendet: Montag, 23. März 2009 18:32
>> An: user@ode.apache.org
>> Betreff: Problem with flow and extension activities
>>
>> Hi all,
>>
>> in the SMILA project we are using extension activities to execute
> java
>> code in BPEL. This works without any problems.
>>
>> Now I tried to execute two extension activities concurrently within a
>> <flow> (see attachment). The execution still works, but the extension
>> activities are not executed concurrently but in sequence. I debugged
>> and
>> found that the extension activities are executed by the same thread.
>>
>> We currently use ODE 2.0.
>>
>> Is there any error on my bpel workflow ? Or is there a ThreadPool
>> that's
>> size needs to be increased ? Or some other configuration option ?
>>
>> Thanks for your help!
>>
>> Bye,
>> Daniel
>
>
--
Rafał Rusin
http://www.touk.pl
http://www.mimuw.edu.pl/~rrusin
RE: Concurrent execution of Invokes in in-memory processes
Posted by Ju...@empolis.com.
Hi,
> OK, I'll prepare the patch for this (next week, probably ;-).
Here it is: https://issues.apache.org/jira/browse/ODE-599
Cheers,
Juergen.
RE: Concurrent execution of Invokes in in-memory processes
Posted by Ju...@empolis.com.
Thanks for the feedback, Matthieu.
> > I played around a bit with this and for a start just changed the
> > special handling of in-memory processes in
> > org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
> > [...]
> > ... and it worked fine in our use case and it didn't make any notable
> > difference in your unit tests ("buildr test" in trunk). Is it really that simple?
> > Then I could provide a patch to make this configurable (globally in
> > OdeConfigProperties?
> > Or per process in deploy.xml? Maybe better, because performance is
> > probably better with synchronous execution so it would make sense to enable this only
> > for processes that actually contain <flow>s).
> >
> > Or are there any pitfalls with this approach?
>
> I don't think so, the code between the two methods is very similar
> anyway if you don't consider the transaction suspend in the in-mem case.
>
> I would also favor per-process configuration for this.
OK, I'll prepare the patch for this (next week, probably ;-).
Cheers,
Jürgen.
Re: Concurrent execution of Invokes in in-memory processes
Posted by Matthieu Riou <ma...@gmail.com>.
On Mon, Apr 27, 2009 at 7:07 AM, <Ju...@empolis.com> wrote:
> Hi (again ;-)
>
> here's another question I posted some days ago. I changed the subject
> because
> it actually not about extension activities (sorry, I should have done this
> last time already), the discussion just started in a thread about them.
>
> Any thoughts about this?
>
> Regards,
> Juergen.
>
> -----Original Message-----
> From: Juergen.Schumacher@empolis.com [mailto:
> Juergen.Schumacher@empolis.com]
> Sent: Thursday, April 16, 2009 5:35 PM
> To: dev@ode.apache.org
> Subject: RE: Problem with flow and extension activities
>
> Hi,
>
> I'm moving this from user@ to dev@ ...
>
> > -----Original Message-----
> > From: Matthieu Riou [mailto:matthieu.riou@gmail.com]
> > Sent: Wednesday, April 01, 2009 6:36 PM
> > Subject: Re: Problem with flow and extension activities
> >
> > On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
> >
> > > we took a look at the code and it seems that in the case of
> > > <in-memory>true</in-memory> parallel execution is not supported at all.
> > > - Was this implemented by design ?
> >
> > Yes, that's very likely. Although I wouldn't have any problem altering
> > that design decision to offer a choice.
>
> I played around a bit with this and for a start just changed the special
> handling of
> in-memory processes in
> org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
>
> if (_process.isInMemory()) {
> // replaced code:
> // invokeInMem(mexDao, partnerEpr, myRoleEpr, operation,
> supportedStyles, oneway);
> invokePersisted(mexDao, partnerEpr, myRoleEpr, operation,
> supportedStyles);
> } else {
> invokePersisted(mexDao, partnerEpr, myRoleEpr, operation,
> supportedStyles);
> }
>
> ... and it worked fine in our use case and it didn't make any notable
> difference in
> your unit tests ("buildr test" in trunk). Is it really that simple?
> Then I could provide a patch to make this configurable (globally in
> OdeConfigProperties?
> Or per process in deploy.xml? Maybe better, because performance is probably
> better
> with synchronous execution so it would make sense to enable this only for
> processes that
> actually contain <flow>s).
>
> Or are there any pitfalls with this approach?
>
I don't think so, the code between the two methods is very similar anyway if
you don't consider the transaction suspend in the in-mem case.
I would also favor per-process configuration for this.
Thanks,
Matthieu
>
> Cheers,
> Juergen.
>
>
Concurrent execution of Invokes in in-memory processes
Posted by Ju...@empolis.com.
Hi (again ;-)
here's another question I posted some days ago. I changed the subject because
it actually not about extension activities (sorry, I should have done this
last time already), the discussion just started in a thread about them.
Any thoughts about this?
Regards,
Juergen.
-----Original Message-----
From: Juergen.Schumacher@empolis.com [mailto:Juergen.Schumacher@empolis.com]
Sent: Thursday, April 16, 2009 5:35 PM
To: dev@ode.apache.org
Subject: RE: Problem with flow and extension activities
Hi,
I'm moving this from user@ to dev@ ...
> -----Original Message-----
> From: Matthieu Riou [mailto:matthieu.riou@gmail.com]
> Sent: Wednesday, April 01, 2009 6:36 PM
> Subject: Re: Problem with flow and extension activities
>
> On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
>
> > we took a look at the code and it seems that in the case of
> > <in-memory>true</in-memory> parallel execution is not supported at all.
> > - Was this implemented by design ?
>
> Yes, that's very likely. Although I wouldn't have any problem altering
> that design decision to offer a choice.
I played around a bit with this and for a start just changed the special handling of
in-memory processes in org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
if (_process.isInMemory()) {
// replaced code:
// invokeInMem(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles, oneway);
invokePersisted(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles);
} else {
invokePersisted(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles);
}
... and it worked fine in our use case and it didn't make any notable difference in
your unit tests ("buildr test" in trunk). Is it really that simple?
Then I could provide a patch to make this configurable (globally in OdeConfigProperties?
Or per process in deploy.xml? Maybe better, because performance is probably better
with synchronous execution so it would make sense to enable this only for processes that
actually contain <flow>s).
Or are there any pitfalls with this approach?
Cheers,
Juergen.
RE: Problem with flow and extension activities
Posted by Ju...@empolis.com.
Hi,
I'm moving this from user@ to dev@ ...
> -----Original Message-----
> From: Matthieu Riou [mailto:matthieu.riou@gmail.com]
> Sent: Wednesday, April 01, 2009 6:36 PM
> Subject: Re: Problem with flow and extension activities
>
> On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
>
> > we took a look at the code and it seems that in the case of
> > <in-memory>true</in-memory> parallel execution is not supported at all.
> > - Was this implemented by design ?
>
> Yes, that's very likely. Although I wouldn't have any problem altering
> that design decision to offer a choice.
I played around a bit with this and for a start just changed the special handling of
in-memory processes in org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
if (_process.isInMemory()) {
// replaced code:
// invokeInMem(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles, oneway);
invokePersisted(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles);
} else {
invokePersisted(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles);
}
... and it worked fine in our use case and it didn't make any notable difference in
your unit tests ("buildr test" in trunk). Is it really that simple?
Then I could provide a patch to make this configurable (globally in OdeConfigProperties?
Or per process in deploy.xml? Maybe better, because performance is probably better
with synchronous execution so it would make sense to enable this only for processes that
actually contain <flow>s).
Or are there any pitfalls with this approach?
Cheers,
Juergen.
Re: Problem with flow and extension activities
Posted by Matthieu Riou <ma...@gmail.com>.
On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
> Hi all,
>
> we took a look at the code and it seems that in the case of
> <in-memory>true</in-memory> parallel execution is not supported at all.
> - Was this implemented by design ?
Yes, that's very likely. Although I wouldn't have any problem altering that
design decision to offer a choice.
>
> - Are there any prerequisites for parallel execution that are not fulfilled
> in the in-memory case ?
It's not tied to parallel execution per se, more the the constraints
surrounding in-memory invocation. We have to be careful with the lifecycle
of those.
>
> - Would it be possible to change the implementation to support parallel
> execution ?
Certainly.
Matthieu
>
> We have a high interest in this functionality and are willing to offer our
> support.
>
> Bye,
> Daniel
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> > Gesendet: Freitag, 27. März 2009 17:47
> > An: user@ode.apache.org
> > Betreff: AW: Problem with flow and extension activities
> >
> > After some more experimenting I found out something interesting:
> >
> > In the <process> of my deploy.xml <in-memory> was set to "true", which
> > apparently caused the sequential execution.
> > When setting it to "false" the invokes are executed concurrently !!!
> >
> > Is this a known issue that concurrency is not possible with <in-memory>
> > set to "true" ?
> >
> > In addition when using <in-memory> set to "true" there must be some
> > kind of timeout. I set the runtime of my webservice to 2 minutes. The
> > second call to the webservice was executed exactly after 1 minute. So
> > it gives you the impression that the second call is concurrent wioth a
> > delay, but I assume that the first invoke is aborted (in the engine)
> > and the 2nd call is therefore in sequence.
> >
> > Bye,
> > Daniel
> >
>
Re: Concurrent execution of extension activities
Posted by Matthieu Riou <ma...@gmail.com>.
On Mon, Apr 27, 2009 at 12:51 PM, Tammo van Lessen <tv...@gmail.com>wrote:
> Matthieu Riou wrote:
> > You can't start a thread that will do something at the Jacob level. When
> you
> > think of it, the main purpose of Jacob is to avoid multi-threading by
> using
> > a cooperative and lightweight threading model. The way you do parrallel
> > stuff in Jacob is by injecting more threads.
> >
> > So I guess the question becomes: what do you need a thread for in your
> > extension?
>
> For non-blocking extension activities. AFAIK a new thread is the only
> way to run the extension code independently from the jacob loop.
> Long-running code in JacobRunnable.run() would block the whole
> navigation. Instead, this code can run in a different thread and mark
> the activity completed once its finished. That's at least what I had in
> mind. So I guess we'd need to find a way to synchronize both threads?
>
> Would there be a more elegant way to generically allow for custom
> long-running code?
>
I think so yes. We should probably have a specific channel for extension
activities that extension runnables could listen to (accepting any
Serialzable for example). Then external code could fire the channel when the
async processing is done. It'd look very much like what we're doing for all
BPEL activities right now and would probably be easier than greenspuning
Java multi-threading in Jacob.
Makes sense?
Cheers,
Matthieu
>
> Cheers,
> Tammo
>
> --
> Tammo van Lessen - http://www.taval.de
>
Re: Concurrent execution of extension activities
Posted by Tammo van Lessen <tv...@gmail.com>.
Matthieu Riou wrote:
> You can't start a thread that will do something at the Jacob level. When you
> think of it, the main purpose of Jacob is to avoid multi-threading by using
> a cooperative and lightweight threading model. The way you do parrallel
> stuff in Jacob is by injecting more threads.
>
> So I guess the question becomes: what do you need a thread for in your
> extension?
For non-blocking extension activities. AFAIK a new thread is the only
way to run the extension code independently from the jacob loop.
Long-running code in JacobRunnable.run() would block the whole
navigation. Instead, this code can run in a different thread and mark
the activity completed once its finished. That's at least what I had in
mind. So I guess we'd need to find a way to synchronize both threads?
Would there be a more elegant way to generically allow for custom
long-running code?
Cheers,
Tammo
--
Tammo van Lessen - http://www.taval.de
Re: Concurrent execution of extension activities
Posted by Matthieu Riou <ma...@gmail.com>.
On Mon, Apr 27, 2009 at 7:03 AM, <Ju...@empolis.com> wrote:
> Hi,
>
> I posted message below some time ago, but there was no response (or did I
> miss it?
> I didn't find anything in the archives, either).
>
> Any idea about it? Tammo?
>
> Thanks in advance for any hint you can give me.
>
> Regards,
> Juergen.
>
>
> -----Original Message-----
> From: Juergen.Schumacher@empolis.com [mailto:
> Juergen.Schumacher@empolis.com]
> Sent: Tuesday, April 14, 2009 3:15 PM
> To: dev@ode.apache.org
> Subject: Concurrent execution of extension activities (RE: Problem with
> flow and extension activities)
>
> Hi Tammo,
>
> > -----Original Message-----
> > From: Tammo van Lessen [mailto:tvanlessen@gmail.com]
> > Sent: Thursday, April 02, 2009 4:17 PM
> > Subject: Re: AW: Problem with flow and extension activities
> >
> > That's true. If you need a concurrent execution of extension activities
> > you'd need to implement the abstract class for async extensions, fork
> > your own thread and call the ExtensionContext.complete method once your
> > processing has finished. In this case the run method can finish before
> > the processing is done and the navigation continues.
>
> I tried this with ODE 2.0 beta2 and put the complete code of my extension
> activity
> execution in a Runnable to be executed in an own thread, but it doesn't
> work yet.
> The code is basically like this:
>
> class MyExtensionActivity extends AbstractAsyncExtensionOperation {
>
> static java.util.concurrent.Executor executor =
> Executors.newCachedThreadPool();
>
> void run(...) {
> executor.execute(new Runnable() {
> public void run() {
> // extension activity code:
> // read variables from ext context
> // do something
> // write variables to ext context
> // complete ext context
> }
> }
> }
> }
>
> For in-memory=true there is an exception when I try to complete the
> ExtensionContext:
>
> java.lang.NullPointerException
> at
> org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
> at
> org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
> at $Proxy42.completed(Unknown Source)
> at
> org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.complete(ExtensionContextImpl.java:147)
>
> So the actual execution of the extension code has worked in this case.
>
> For in-memory=false I get an exception when trying to read a variable in my
> separate thread:
>
> java.lang.NullPointerException
> at
> org.apache.ode.dao.jpa.ProcessInstanceDAOImpl.getScope(ProcessInstanceDAOImpl.java:231)
> at
> org.apache.ode.bpel.engine.BpelRuntimeContextImpl.fetchVariableData(BpelRuntimeContextImpl.java:354)
> at
> org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl.fetchVariableData(RuntimeInstanceImpl.java:155)
> at
> org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:90)
> at
> org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:108)
>
> which means that the DAO impl cannot find it's associated JPA entity
> manager anymore.
> So it seems I cannot access the variables in the extension context in this
> case.
>
> And then there's another exception on completeWithFault() that looks
> similar to the above:
>
> Exception in thread "pool-2-thread-3" java.lang.NullPointerException
> at
> org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
> at
> org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
> at $Proxy40.completed(Unknown Source)
> at
> org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.completeWithFault(ExtensionContextImpl.java:162)
>
> It doesn't matter if my extension activities are actually called from
> within a <flow> or not.
> It also didn't change anything to let my extension implementation extend
> AbstractAsyncExtensionOperation
> instead of just implementing ExtensionOperation (I also did not find
> anything in the ODE code, where they
> are treated differently). Or have there been changes since 2.0-beta2 that
> make this work?
>
> Or is there just something I am missing or that I have misunderstood? (-;
>
You can't start a thread that will do something at the Jacob level. When you
think of it, the main purpose of Jacob is to avoid multi-threading by using
a cooperative and lightweight threading model. The way you do parrallel
stuff in Jacob is by injecting more threads.
So I guess the question becomes: what do you need a thread for in your
extension?
Matthieu
> Thanks for your patience,
> Juergen.
>
>
Re: Concurrent execution of extension activities
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi Jürgen,
I have noticed your mail but I was quite busy last weeks. Also this week
is very tough, so I hope to find some time for a deep dive afterwards.
But perhaps the other devs have some idea about what's causing that NPE.
Best,
Tammo
Juergen.Schumacher@empolis.com wrote:
> Hi,
>
> I posted message below some time ago, but there was no response (or did I miss it?
> I didn't find anything in the archives, either).
>
> Any idea about it? Tammo?
>
> Thanks in advance for any hint you can give me.
>
> Regards,
> Juergen.
>
>
> -----Original Message-----
> From: Juergen.Schumacher@empolis.com [mailto:Juergen.Schumacher@empolis.com]
> Sent: Tuesday, April 14, 2009 3:15 PM
> To: dev@ode.apache.org
> Subject: Concurrent execution of extension activities (RE: Problem with flow and extension activities)
>
> Hi Tammo,
>
>> -----Original Message-----
>> From: Tammo van Lessen [mailto:tvanlessen@gmail.com]
>> Sent: Thursday, April 02, 2009 4:17 PM
>> Subject: Re: AW: Problem with flow and extension activities
>>
>> That's true. If you need a concurrent execution of extension activities
>> you'd need to implement the abstract class for async extensions, fork
>> your own thread and call the ExtensionContext.complete method once your
>> processing has finished. In this case the run method can finish before
>> the processing is done and the navigation continues.
>
> I tried this with ODE 2.0 beta2 and put the complete code of my extension activity
> execution in a Runnable to be executed in an own thread, but it doesn't work yet.
> The code is basically like this:
>
> class MyExtensionActivity extends AbstractAsyncExtensionOperation {
>
> static java.util.concurrent.Executor executor = Executors.newCachedThreadPool();
>
> void run(...) {
> executor.execute(new Runnable() {
> public void run() {
> // extension activity code:
> // read variables from ext context
> // do something
> // write variables to ext context
> // complete ext context
> }
> }
> }
> }
>
> For in-memory=true there is an exception when I try to complete the ExtensionContext:
>
> java.lang.NullPointerException
> at org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
> at org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
> at $Proxy42.completed(Unknown Source)
> at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.complete(ExtensionContextImpl.java:147)
>
> So the actual execution of the extension code has worked in this case.
>
> For in-memory=false I get an exception when trying to read a variable in my separate thread:
>
> java.lang.NullPointerException
> at org.apache.ode.dao.jpa.ProcessInstanceDAOImpl.getScope(ProcessInstanceDAOImpl.java:231)
> at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.fetchVariableData(BpelRuntimeContextImpl.java:354)
> at org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl.fetchVariableData(RuntimeInstanceImpl.java:155)
> at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:90)
> at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:108)
>
> which means that the DAO impl cannot find it's associated JPA entity manager anymore.
> So it seems I cannot access the variables in the extension context in this case.
>
> And then there's another exception on completeWithFault() that looks similar to the above:
>
> Exception in thread "pool-2-thread-3" java.lang.NullPointerException
> at org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
> at org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
> at $Proxy40.completed(Unknown Source)
> at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.completeWithFault(ExtensionContextImpl.java:162)
>
> It doesn't matter if my extension activities are actually called from within a <flow> or not.
> It also didn't change anything to let my extension implementation extend AbstractAsyncExtensionOperation
> instead of just implementing ExtensionOperation (I also did not find anything in the ODE code, where they
> are treated differently). Or have there been changes since 2.0-beta2 that make this work?
>
> Or is there just something I am missing or that I have misunderstood? (-;
>
> Thanks for your patience,
> Juergen.
>
--
Tammo van Lessen - http://www.taval.de
RE: Concurrent execution of extension activities
Posted by Ju...@empolis.com.
Hi,
I posted message below some time ago, but there was no response (or did I miss it?
I didn't find anything in the archives, either).
Any idea about it? Tammo?
Thanks in advance for any hint you can give me.
Regards,
Juergen.
-----Original Message-----
From: Juergen.Schumacher@empolis.com [mailto:Juergen.Schumacher@empolis.com]
Sent: Tuesday, April 14, 2009 3:15 PM
To: dev@ode.apache.org
Subject: Concurrent execution of extension activities (RE: Problem with flow and extension activities)
Hi Tammo,
> -----Original Message-----
> From: Tammo van Lessen [mailto:tvanlessen@gmail.com]
> Sent: Thursday, April 02, 2009 4:17 PM
> Subject: Re: AW: Problem with flow and extension activities
>
> That's true. If you need a concurrent execution of extension activities
> you'd need to implement the abstract class for async extensions, fork
> your own thread and call the ExtensionContext.complete method once your
> processing has finished. In this case the run method can finish before
> the processing is done and the navigation continues.
I tried this with ODE 2.0 beta2 and put the complete code of my extension activity
execution in a Runnable to be executed in an own thread, but it doesn't work yet.
The code is basically like this:
class MyExtensionActivity extends AbstractAsyncExtensionOperation {
static java.util.concurrent.Executor executor = Executors.newCachedThreadPool();
void run(...) {
executor.execute(new Runnable() {
public void run() {
// extension activity code:
// read variables from ext context
// do something
// write variables to ext context
// complete ext context
}
}
}
}
For in-memory=true there is an exception when I try to complete the ExtensionContext:
java.lang.NullPointerException
at org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
at org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
at $Proxy42.completed(Unknown Source)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.complete(ExtensionContextImpl.java:147)
So the actual execution of the extension code has worked in this case.
For in-memory=false I get an exception when trying to read a variable in my separate thread:
java.lang.NullPointerException
at org.apache.ode.dao.jpa.ProcessInstanceDAOImpl.getScope(ProcessInstanceDAOImpl.java:231)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.fetchVariableData(BpelRuntimeContextImpl.java:354)
at org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl.fetchVariableData(RuntimeInstanceImpl.java:155)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:90)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:108)
which means that the DAO impl cannot find it's associated JPA entity manager anymore.
So it seems I cannot access the variables in the extension context in this case.
And then there's another exception on completeWithFault() that looks similar to the above:
Exception in thread "pool-2-thread-3" java.lang.NullPointerException
at org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
at org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
at $Proxy40.completed(Unknown Source)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.completeWithFault(ExtensionContextImpl.java:162)
It doesn't matter if my extension activities are actually called from within a <flow> or not.
It also didn't change anything to let my extension implementation extend AbstractAsyncExtensionOperation
instead of just implementing ExtensionOperation (I also did not find anything in the ODE code, where they
are treated differently). Or have there been changes since 2.0-beta2 that make this work?
Or is there just something I am missing or that I have misunderstood? (-;
Thanks for your patience,
Juergen.
Concurrent execution of extension activities (RE: Problem with flow and extension activities)
Posted by Ju...@empolis.com.
Hi Tammo,
> -----Original Message-----
> From: Tammo van Lessen [mailto:tvanlessen@gmail.com]
> Sent: Thursday, April 02, 2009 4:17 PM
> Subject: Re: AW: Problem with flow and extension activities
>
> That's true. If you need a concurrent execution of extension activities
> you'd need to implement the abstract class for async extensions, fork
> your own thread and call the ExtensionContext.complete method once your
> processing has finished. In this case the run method can finish before
> the processing is done and the navigation continues.
I tried this with ODE 2.0 beta2 and put the complete code of my extension activity
execution in a Runnable to be executed in an own thread, but it doesn't work yet.
The code is basically like this:
class MyExtensionActivity extends AbstractAsyncExtensionOperation {
static java.util.concurrent.Executor executor = Executors.newCachedThreadPool();
void run(...) {
executor.execute(new Runnable() {
public void run() {
// extension activity code:
// read variables from ext context
// do something
// write variables to ext context
// complete ext context
}
}
}
}
For in-memory=true there is an exception when I try to complete the ExtensionContext:
java.lang.NullPointerException
at org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
at org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
at $Proxy42.completed(Unknown Source)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.complete(ExtensionContextImpl.java:147)
So the actual execution of the extension code has worked in this case.
For in-memory=false I get an exception when trying to read a variable in my separate thread:
java.lang.NullPointerException
at org.apache.ode.dao.jpa.ProcessInstanceDAOImpl.getScope(ProcessInstanceDAOImpl.java:231)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.fetchVariableData(BpelRuntimeContextImpl.java:354)
at org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl.fetchVariableData(RuntimeInstanceImpl.java:155)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:90)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.readVariable(ExtensionContextImpl.java:108)
which means that the DAO impl cannot find it's associated JPA entity manager anymore.
So it seems I cannot access the variables in the extension context in this case.
And then there's another exception on completeWithFault() that looks similar to the above:
Exception in thread "pool-2-thread-3" java.lang.NullPointerException
at org.apache.ode.jacob.vpu.JacobVPU.activeJacobThread(JacobVPU.java:203)
at org.apache.ode.jacob.vpu.ChannelFactory$ChannelInvocationHandler.invoke(ChannelFactory.java:89)
at $Proxy40.completed(Unknown Source)
at org.apache.ode.bpel.rtrep.v2.ExtensionContextImpl.completeWithFault(ExtensionContextImpl.java:162)
It doesn't matter if my extension activities are actually called from within a <flow> or not.
It also didn't change anything to let my extension implementation extend AbstractAsyncExtensionOperation
instead of just implementing ExtensionOperation (I also did not find anything in the ODE code, where they
are treated differently). Or have there been changes since 2.0-beta2 that make this work?
Or is there just something I am missing or that I have misunderstood? (-;
Thanks for your patience,
Juergen.
RE: AW: Problem with flow and extension activities
Posted by Ju...@empolis.com.
Hi,
> That's true. If you need a concurrent execution of extension activities
> you'd need to implement the abstract class for async extensions, fork
> your own thread and call the ExtensionContext.complete method once your
> processing has finished. In this case the run method can finish before
> the processing is done and the navigation continues.
>
> HTH,
> Tammo
This certainly helped, thanks. I will give it a try (but probably not this
week anymore).
Cheers,
Juergen.
Re: AW: Problem with flow and extension activities
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi Daniel,
(I'm moving this from user@ to dev@)
> today I found out, that the workaround with setting <in-memory> to
> "false" works only for invokes of webservices, not extension
> activities.
That's true. If you need a concurrent execution of extension activities
you'd need to implement the abstract class for async extensions, fork
your own thread and call the ExtensionContext.complete method once your
processing has finished. In this case the run method can finish before
the processing is done and the navigation continues.
HTH,
Tammo
--
Tammo van Lessen - http://www.taval.de
AW: Problem with flow and extension activities
Posted by Da...@empolis.com.
Hi all,
today I found out, that the workaround with setting <in-memory> to "false" works only for invokes of webservices, not extension activities.
We (to be precise my teammate Jürgen) would like to try to implement a solution for these issues, allowing parallel execution of webservices and extension activities with <in-memory> "true" or "false".
- Could anyone offer some advice were to get started in the code (we use ODE 2.0-beta2) ?
- Is there any code that allows parallel execution in older versions of ODE ?
- Are there any special issues to take care of ?
Thanks for your help.
Bye,
Daniel
Re: Problem with flow and extension activities
Posted by Matthieu Riou <ma...@gmail.com>.
On Wed, Apr 1, 2009 at 9:50 AM, Alex Boisvert <bo...@intalio.com> wrote:
> I'm curious... where in the code do you see that parallel execution is not
> supported for in-memory processes?
It's in the trunk, not 1.x.
Matthieu
>
> alex
>
>
> On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
>
> > Hi all,
> >
> > we took a look at the code and it seems that in the case of
> > <in-memory>true</in-memory> parallel execution is not supported at all.
> > - Was this implemented by design ?
> > - Are there any prerequisites for parallel execution that are not
> fulfilled
> > in the in-memory case ?
> > - Would it be possible to change the implementation to support parallel
> > execution ?
> >
> > We have a high interest in this functionality and are willing to offer
> our
> > support.
> >
> > Bye,
> > Daniel
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> > > Gesendet: Freitag, 27. März 2009 17:47
> > > An: user@ode.apache.org
> > > Betreff: AW: Problem with flow and extension activities
> > >
> > > After some more experimenting I found out something interesting:
> > >
> > > In the <process> of my deploy.xml <in-memory> was set to "true", which
> > > apparently caused the sequential execution.
> > > When setting it to "false" the invokes are executed concurrently !!!
> > >
> > > Is this a known issue that concurrency is not possible with <in-memory>
> > > set to "true" ?
> > >
> > > In addition when using <in-memory> set to "true" there must be some
> > > kind of timeout. I set the runtime of my webservice to 2 minutes. The
> > > second call to the webservice was executed exactly after 1 minute. So
> > > it gives you the impression that the second call is concurrent wioth a
> > > delay, but I assume that the first invoke is aborted (in the engine)
> > > and the 2nd call is therefore in sequence.
> > >
> > > Bye,
> > > Daniel
> > >
> >
>
Re: Problem with flow and extension activities
Posted by Alex Boisvert <bo...@intalio.com>.
I'm curious... where in the code do you see that parallel execution is not
supported for in-memory processes?
alex
On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
> Hi all,
>
> we took a look at the code and it seems that in the case of
> <in-memory>true</in-memory> parallel execution is not supported at all.
> - Was this implemented by design ?
> - Are there any prerequisites for parallel execution that are not fulfilled
> in the in-memory case ?
> - Would it be possible to change the implementation to support parallel
> execution ?
>
> We have a high interest in this functionality and are willing to offer our
> support.
>
> Bye,
> Daniel
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> > Gesendet: Freitag, 27. März 2009 17:47
> > An: user@ode.apache.org
> > Betreff: AW: Problem with flow and extension activities
> >
> > After some more experimenting I found out something interesting:
> >
> > In the <process> of my deploy.xml <in-memory> was set to "true", which
> > apparently caused the sequential execution.
> > When setting it to "false" the invokes are executed concurrently !!!
> >
> > Is this a known issue that concurrency is not possible with <in-memory>
> > set to "true" ?
> >
> > In addition when using <in-memory> set to "true" there must be some
> > kind of timeout. I set the runtime of my webservice to 2 minutes. The
> > second call to the webservice was executed exactly after 1 minute. So
> > it gives you the impression that the second call is concurrent wioth a
> > delay, but I assume that the first invoke is aborted (in the engine)
> > and the 2nd call is therefore in sequence.
> >
> > Bye,
> > Daniel
> >
>
AW: Problem with flow and extension activities
Posted by Da...@empolis.com.
Hi all,
we took a look at the code and it seems that in the case of <in-memory>true</in-memory> parallel execution is not supported at all.
- Was this implemented by design ?
- Are there any prerequisites for parallel execution that are not fulfilled in the in-memory case ?
- Would it be possible to change the implementation to support parallel execution ?
We have a high interest in this functionality and are willing to offer our support.
Bye,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> Gesendet: Freitag, 27. März 2009 17:47
> An: user@ode.apache.org
> Betreff: AW: Problem with flow and extension activities
>
> After some more experimenting I found out something interesting:
>
> In the <process> of my deploy.xml <in-memory> was set to "true", which
> apparently caused the sequential execution.
> When setting it to "false" the invokes are executed concurrently !!!
>
> Is this a known issue that concurrency is not possible with <in-memory>
> set to "true" ?
>
> In addition when using <in-memory> set to "true" there must be some
> kind of timeout. I set the runtime of my webservice to 2 minutes. The
> second call to the webservice was executed exactly after 1 minute. So
> it gives you the impression that the second call is concurrent wioth a
> delay, but I assume that the first invoke is aborted (in the engine)
> and the 2nd call is therefore in sequence.
>
> Bye,
> Daniel
>
AW: Problem with flow and extension activities
Posted by Da...@empolis.com.
After some more experimenting I found out something interesting:
In the <process> of my deploy.xml <in-memory> was set to "true", which apparently caused the sequential execution.
When setting it to "false" the invokes are executed concurrently !!!
Is this a known issue that concurrency is not possible with <in-memory> set to "true" ?
In addition when using <in-memory> set to "true" there must be some kind of timeout. I set the runtime of my webservice to 2 minutes. The second call to the webservice was executed exactly after 1 minute. So it gives you the impression that the second call is concurrent wioth a delay, but I assume that the first invoke is aborted (in the engine) and the 2nd call is therefore in sequence.
Bye,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: Alex Boisvert [mailto:boisvert@intalio.com]
> Gesendet: Freitag, 27. März 2009 16:11
> An: user@ode.apache.org
> Betreff: Re: Problem with flow and extension activities
>
> How long are your invokes? Sub-second or greater than a few seconds?
> I
> suggest you try for yourself with invokes that take more than a few
> seconds.
>
> I'd be happy to review the evidence that supports your proof. :)
>
> alex
>
>
> On Fri, Mar 27, 2009 at 8:06 AM, <Da...@empolis.com> wrote:
>
> > Hi Alex,
> >
> > as far I understand your answer you are saying that the two invokes
> from my
> > example should be executed concurrently.
> > My tests however prove that both are executed in sequence.
> >
> > I've read the Jacob tutorial but found it not really helpful to my
> problem.
> > My use case is really simple:
> > I want to call two webservices (or extension activities), each
> executing a
> > search (running few seconds). In order to reduce runtime I want them
> to be
> > called concurrently, so that the runtime is MAX(T1, T2). At the
> moment the
> > runtime is T1+T2.
> >
> > Has no one else had a similar use case ?
> >
> > Bye,
> > Daniel
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Alex Boisvert [mailto:boisvert@intalio.com]
> > > Gesendet: Dienstag, 24. März 2009 14:55
> > > An: user@ode.apache.org
> > > Betreff: Re: Problem with flow and extension activities
> > >
> > > You may want to go through our Jacob tutorial to understand the
> > > concurrency
> > > semantics,
> > > http://ode.apache.org/jacob.html
> > >
> > > Essentially, inside the engine all process instances operations are
> > > serialized (through Jacob and the instance lock) to avoid
> concurrency
> > > issues. Activities that may block or take a long time are
> designed
> > > in
> > > such a way that they do not block inside the engine, instead they
> > > register a
> > > channel and use it for callback when the asynchronous
> response/event
> > > occurs.
> > >
> > > The invoke activity is a good example of that. Only one invoke
> will
> > > be
> > > initiated at once, although multiple invokes can be pending and
> > > executed
> > > concurrently. So in effect, the serialization only applies to the
> > > engine
> > > reaching out to the integration layer and requesting to perform an
> > > invoke. The invokes are handled concurrency by the integration
> layer
> > > in a
> > > different thread.
> > >
> > > In your case, you'd see something like,
> > >
> > > [Thread 1: operations are serialized]
> > > T1 start flow
> > > T1 start invoke 1
> > > T1 start invoke 2
> > > T1 commit
> > >
> > > [Thread 2 and 3: invokes happen concurrently]
> > > T2 perform invoke 2
> > > T3 perform invoke 2
> > >
> > > T2 receives response, updates message exchange
> > > T2 enters the engine, obtains instance lock
> > > T2 updates instance state
> > > T2 commit
> > >
> > > T3 receives response, updates message exchange
> > > T3 enters the engine, obtains instance lock
> > > T3 updates instance state
> > > T3 if there's something else to do after the flow, do it
> > > T3 ... runs until some activity require async response/event
> > > T3 commit
> > >
> > > Hope this helps,
> > > alex
> > >
> > > On Tue, Mar 24, 2009 at 3:43 AM, <Da...@empolis.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > the problem seems not to be related to extension activities only.
> I
> > > did a
> > > > test invoking webservices:
> > > >
> > > > ...
> > > > <flow>
> > > > <invoke name="sayHi" partnerLink="HelloWorld"
> > > > portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
> > > > outputVariable="response">
> > > > </invoke>
> > > >
> > > > <invoke name="sayHo" partnerLink="HelloWorld"
> > > > portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
> > > > outputVariable="response2">
> > > > </invoke>
> > > > </flow>
> > > > ...
> > > >
> > > > The two invoke elements are executed in random order. However
> the
> > > second
> > > > invoke call is not executed until the first invoke returns. It
> seems
> > > that
> > > > the same Thread is used to execute the invoke calls. We use the
> > > integrated
> > > > SimpleScheduler.
> > > >
> > > > Anyone any ideas what's going wrong here ?
> > > >
> > > > Bye,
> > > > Daniel
> > > >
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Daniel.Stucky@empolis.com
> [mailto:Daniel.Stucky@empolis.com]
> > > > > Gesendet: Montag, 23. März 2009 18:32
> > > > > An: user@ode.apache.org
> > > > > Betreff: Problem with flow and extension activities
> > > > >
> > > > > Hi all,
> > > > >
> > > > > in the SMILA project we are using extension activities to
> execute
> > > > java
> > > > > code in BPEL. This works without any problems.
> > > > >
> > > > > Now I tried to execute two extension activities concurrently
> within
> > > a
> > > > > <flow> (see attachment). The execution still works, but the
> > > extension
> > > > > activities are not executed concurrently but in sequence. I
> > > debugged
> > > > > and
> > > > > found that the extension activities are executed by the same
> > > thread.
> > > > >
> > > > > We currently use ODE 2.0.
> > > > >
> > > > > Is there any error on my bpel workflow ? Or is there a
> ThreadPool
> > > > > that's
> > > > > size needs to be increased ? Or some other configuration option
> ?
> > > > >
> > > > > Thanks for your help!
> > > > >
> > > > > Bye,
> > > > > Daniel
> > > >
> > > >
> >
Re: Problem with flow and extension activities
Posted by Alex Boisvert <bo...@intalio.com>.
How long are your invokes? Sub-second or greater than a few seconds? I
suggest you try for yourself with invokes that take more than a few seconds.
I'd be happy to review the evidence that supports your proof. :)
alex
On Fri, Mar 27, 2009 at 8:06 AM, <Da...@empolis.com> wrote:
> Hi Alex,
>
> as far I understand your answer you are saying that the two invokes from my
> example should be executed concurrently.
> My tests however prove that both are executed in sequence.
>
> I've read the Jacob tutorial but found it not really helpful to my problem.
> My use case is really simple:
> I want to call two webservices (or extension activities), each executing a
> search (running few seconds). In order to reduce runtime I want them to be
> called concurrently, so that the runtime is MAX(T1, T2). At the moment the
> runtime is T1+T2.
>
> Has no one else had a similar use case ?
>
> Bye,
> Daniel
>
> > -----Ursprüngliche Nachricht-----
> > Von: Alex Boisvert [mailto:boisvert@intalio.com]
> > Gesendet: Dienstag, 24. März 2009 14:55
> > An: user@ode.apache.org
> > Betreff: Re: Problem with flow and extension activities
> >
> > You may want to go through our Jacob tutorial to understand the
> > concurrency
> > semantics,
> > http://ode.apache.org/jacob.html
> >
> > Essentially, inside the engine all process instances operations are
> > serialized (through Jacob and the instance lock) to avoid concurrency
> > issues. Activities that may block or take a long time are designed
> > in
> > such a way that they do not block inside the engine, instead they
> > register a
> > channel and use it for callback when the asynchronous response/event
> > occurs.
> >
> > The invoke activity is a good example of that. Only one invoke will
> > be
> > initiated at once, although multiple invokes can be pending and
> > executed
> > concurrently. So in effect, the serialization only applies to the
> > engine
> > reaching out to the integration layer and requesting to perform an
> > invoke. The invokes are handled concurrency by the integration layer
> > in a
> > different thread.
> >
> > In your case, you'd see something like,
> >
> > [Thread 1: operations are serialized]
> > T1 start flow
> > T1 start invoke 1
> > T1 start invoke 2
> > T1 commit
> >
> > [Thread 2 and 3: invokes happen concurrently]
> > T2 perform invoke 2
> > T3 perform invoke 2
> >
> > T2 receives response, updates message exchange
> > T2 enters the engine, obtains instance lock
> > T2 updates instance state
> > T2 commit
> >
> > T3 receives response, updates message exchange
> > T3 enters the engine, obtains instance lock
> > T3 updates instance state
> > T3 if there's something else to do after the flow, do it
> > T3 ... runs until some activity require async response/event
> > T3 commit
> >
> > Hope this helps,
> > alex
> >
> > On Tue, Mar 24, 2009 at 3:43 AM, <Da...@empolis.com> wrote:
> >
> > > Hi all,
> > >
> > > the problem seems not to be related to extension activities only. I
> > did a
> > > test invoking webservices:
> > >
> > > ...
> > > <flow>
> > > <invoke name="sayHi" partnerLink="HelloWorld"
> > > portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
> > > outputVariable="response">
> > > </invoke>
> > >
> > > <invoke name="sayHo" partnerLink="HelloWorld"
> > > portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
> > > outputVariable="response2">
> > > </invoke>
> > > </flow>
> > > ...
> > >
> > > The two invoke elements are executed in random order. However the
> > second
> > > invoke call is not executed until the first invoke returns. It seems
> > that
> > > the same Thread is used to execute the invoke calls. We use the
> > integrated
> > > SimpleScheduler.
> > >
> > > Anyone any ideas what's going wrong here ?
> > >
> > > Bye,
> > > Daniel
> > >
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> > > > Gesendet: Montag, 23. März 2009 18:32
> > > > An: user@ode.apache.org
> > > > Betreff: Problem with flow and extension activities
> > > >
> > > > Hi all,
> > > >
> > > > in the SMILA project we are using extension activities to execute
> > > java
> > > > code in BPEL. This works without any problems.
> > > >
> > > > Now I tried to execute two extension activities concurrently within
> > a
> > > > <flow> (see attachment). The execution still works, but the
> > extension
> > > > activities are not executed concurrently but in sequence. I
> > debugged
> > > > and
> > > > found that the extension activities are executed by the same
> > thread.
> > > >
> > > > We currently use ODE 2.0.
> > > >
> > > > Is there any error on my bpel workflow ? Or is there a ThreadPool
> > > > that's
> > > > size needs to be increased ? Or some other configuration option ?
> > > >
> > > > Thanks for your help!
> > > >
> > > > Bye,
> > > > Daniel
> > >
> > >
>
AW: Problem with flow and extension activities
Posted by Da...@empolis.com.
Hi Alex,
as far I understand your answer you are saying that the two invokes from my example should be executed concurrently.
My tests however prove that both are executed in sequence.
I've read the Jacob tutorial but found it not really helpful to my problem. My use case is really simple:
I want to call two webservices (or extension activities), each executing a search (running few seconds). In order to reduce runtime I want them to be called concurrently, so that the runtime is MAX(T1, T2). At the moment the runtime is T1+T2.
Has no one else had a similar use case ?
Bye,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: Alex Boisvert [mailto:boisvert@intalio.com]
> Gesendet: Dienstag, 24. März 2009 14:55
> An: user@ode.apache.org
> Betreff: Re: Problem with flow and extension activities
>
> You may want to go through our Jacob tutorial to understand the
> concurrency
> semantics,
> http://ode.apache.org/jacob.html
>
> Essentially, inside the engine all process instances operations are
> serialized (through Jacob and the instance lock) to avoid concurrency
> issues. Activities that may block or take a long time are designed
> in
> such a way that they do not block inside the engine, instead they
> register a
> channel and use it for callback when the asynchronous response/event
> occurs.
>
> The invoke activity is a good example of that. Only one invoke will
> be
> initiated at once, although multiple invokes can be pending and
> executed
> concurrently. So in effect, the serialization only applies to the
> engine
> reaching out to the integration layer and requesting to perform an
> invoke. The invokes are handled concurrency by the integration layer
> in a
> different thread.
>
> In your case, you'd see something like,
>
> [Thread 1: operations are serialized]
> T1 start flow
> T1 start invoke 1
> T1 start invoke 2
> T1 commit
>
> [Thread 2 and 3: invokes happen concurrently]
> T2 perform invoke 2
> T3 perform invoke 2
>
> T2 receives response, updates message exchange
> T2 enters the engine, obtains instance lock
> T2 updates instance state
> T2 commit
>
> T3 receives response, updates message exchange
> T3 enters the engine, obtains instance lock
> T3 updates instance state
> T3 if there's something else to do after the flow, do it
> T3 ... runs until some activity require async response/event
> T3 commit
>
> Hope this helps,
> alex
>
> On Tue, Mar 24, 2009 at 3:43 AM, <Da...@empolis.com> wrote:
>
> > Hi all,
> >
> > the problem seems not to be related to extension activities only. I
> did a
> > test invoking webservices:
> >
> > ...
> > <flow>
> > <invoke name="sayHi" partnerLink="HelloWorld"
> > portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
> > outputVariable="response">
> > </invoke>
> >
> > <invoke name="sayHo" partnerLink="HelloWorld"
> > portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
> > outputVariable="response2">
> > </invoke>
> > </flow>
> > ...
> >
> > The two invoke elements are executed in random order. However the
> second
> > invoke call is not executed until the first invoke returns. It seems
> that
> > the same Thread is used to execute the invoke calls. We use the
> integrated
> > SimpleScheduler.
> >
> > Anyone any ideas what's going wrong here ?
> >
> > Bye,
> > Daniel
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> > > Gesendet: Montag, 23. März 2009 18:32
> > > An: user@ode.apache.org
> > > Betreff: Problem with flow and extension activities
> > >
> > > Hi all,
> > >
> > > in the SMILA project we are using extension activities to execute
> > java
> > > code in BPEL. This works without any problems.
> > >
> > > Now I tried to execute two extension activities concurrently within
> a
> > > <flow> (see attachment). The execution still works, but the
> extension
> > > activities are not executed concurrently but in sequence. I
> debugged
> > > and
> > > found that the extension activities are executed by the same
> thread.
> > >
> > > We currently use ODE 2.0.
> > >
> > > Is there any error on my bpel workflow ? Or is there a ThreadPool
> > > that's
> > > size needs to be increased ? Or some other configuration option ?
> > >
> > > Thanks for your help!
> > >
> > > Bye,
> > > Daniel
> >
> >
Re: Problem with flow and extension activities
Posted by Alex Boisvert <bo...@intalio.com>.
You may want to go through our Jacob tutorial to understand the concurrency
semantics,
http://ode.apache.org/jacob.html
Essentially, inside the engine all process instances operations are
serialized (through Jacob and the instance lock) to avoid concurrency
issues. Activities that may block or take a long time are designed in
such a way that they do not block inside the engine, instead they register a
channel and use it for callback when the asynchronous response/event occurs.
The invoke activity is a good example of that. Only one invoke will be
initiated at once, although multiple invokes can be pending and executed
concurrently. So in effect, the serialization only applies to the engine
reaching out to the integration layer and requesting to perform an
invoke. The invokes are handled concurrency by the integration layer in a
different thread.
In your case, you'd see something like,
[Thread 1: operations are serialized]
T1 start flow
T1 start invoke 1
T1 start invoke 2
T1 commit
[Thread 2 and 3: invokes happen concurrently]
T2 perform invoke 2
T3 perform invoke 2
T2 receives response, updates message exchange
T2 enters the engine, obtains instance lock
T2 updates instance state
T2 commit
T3 receives response, updates message exchange
T3 enters the engine, obtains instance lock
T3 updates instance state
T3 if there's something else to do after the flow, do it
T3 ... runs until some activity require async response/event
T3 commit
Hope this helps,
alex
On Tue, Mar 24, 2009 at 3:43 AM, <Da...@empolis.com> wrote:
> Hi all,
>
> the problem seems not to be related to extension activities only. I did a
> test invoking webservices:
>
> ...
> <flow>
> <invoke name="sayHi" partnerLink="HelloWorld"
> portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
> outputVariable="response">
> </invoke>
>
> <invoke name="sayHo" partnerLink="HelloWorld"
> portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
> outputVariable="response2">
> </invoke>
> </flow>
> ...
>
> The two invoke elements are executed in random order. However the second
> invoke call is not executed until the first invoke returns. It seems that
> the same Thread is used to execute the invoke calls. We use the integrated
> SimpleScheduler.
>
> Anyone any ideas what's going wrong here ?
>
> Bye,
> Daniel
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> > Gesendet: Montag, 23. März 2009 18:32
> > An: user@ode.apache.org
> > Betreff: Problem with flow and extension activities
> >
> > Hi all,
> >
> > in the SMILA project we are using extension activities to execute
> java
> > code in BPEL. This works without any problems.
> >
> > Now I tried to execute two extension activities concurrently within a
> > <flow> (see attachment). The execution still works, but the extension
> > activities are not executed concurrently but in sequence. I debugged
> > and
> > found that the extension activities are executed by the same thread.
> >
> > We currently use ODE 2.0.
> >
> > Is there any error on my bpel workflow ? Or is there a ThreadPool
> > that's
> > size needs to be increased ? Or some other configuration option ?
> >
> > Thanks for your help!
> >
> > Bye,
> > Daniel
>
>
AW: Problem with flow and extension activities
Posted by Da...@empolis.com.
Hi all,
the problem seems not to be related to extension activities only. I did a test invoking webservices:
...
<flow>
<invoke name="sayHi" partnerLink="HelloWorld"
portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
outputVariable="response">
</invoke>
<invoke name="sayHo" partnerLink="HelloWorld"
portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
outputVariable="response2">
</invoke>
</flow>
...
The two invoke elements are executed in random order. However the second invoke call is not executed until the first invoke returns. It seems that the same Thread is used to execute the invoke calls. We use the integrated SimpleScheduler.
Anyone any ideas what's going wrong here ?
Bye,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> Gesendet: Montag, 23. März 2009 18:32
> An: user@ode.apache.org
> Betreff: Problem with flow and extension activities
>
> Hi all,
>
> in the SMILA project we are using extension activities to execute
java
> code in BPEL. This works without any problems.
>
> Now I tried to execute two extension activities concurrently within a
> <flow> (see attachment). The execution still works, but the extension
> activities are not executed concurrently but in sequence. I debugged
> and
> found that the extension activities are executed by the same thread.
>
> We currently use ODE 2.0.
>
> Is there any error on my bpel workflow ? Or is there a ThreadPool
> that's
> size needs to be increased ? Or some other configuration option ?
>
> Thanks for your help!
>
> Bye,
> Daniel
AW: Problem with flow and extension activities
Posted by Da...@empolis.com.
Hi all,
the problem seems not to be related to extension activities only. I did a test invoking webservices:
...
<flow>
<invoke name="sayHi" partnerLink="HelloWorld" portType="hw:HelloWorld" operation="sayHi" inputVariable="hi"
outputVariable="response">
</invoke>
<invoke name="sayHo" partnerLink="HelloWorld" portType="hw:HelloWorld" operation="sayHi" inputVariable="ho"
outputVariable="response2">
</invoke>
</flow>
...
The two invoke elements are executed in random order. However the second invoke call is not executed until the first invoke returns.
It seems that the same Thread is used to execute the invoke calls. We use the integrated SimpleScheduler.
Anyone any ideas whats going wrong here ?
Bye,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: Daniel.Stucky@empolis.com [mailto:Daniel.Stucky@empolis.com]
> Gesendet: Montag, 23. März 2009 18:32
> An: user@ode.apache.org
> Betreff: Problem with flow and extension activities
>
> Hi all,
>
> in the SMILA project we are using extension activities to execute java
> code in BPEL. This works without any problems.
>
> Now I tried to execute two extension activities concurrently within a
> <flow> (see attachment). The execution still works, but the extension
> activities are not executed concurrently but in sequence. I debugged
> and
> found that the extension activities are executed by the same thread.
>
> We currently use ODE 2.0.
>
> Is there any error on my bpel workflow ? Or is there a ThreadPool
> that's
> size needs to be increased ? Or some other configuration option ?
>
> Thanks for your help!
>
> Bye,
> Daniel