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/04/01 11:56:46 UTC

AW: Problem with flow and extension activities

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: 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