ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]
Date Thu, 05 Jun 2008 18:11:06 GMT
Okay, this took a while because it was actually far trickier than I
expected. Here were the two problems (the first being the serious one):

 * When OpenJPA first connects to the DB it initializes its sequence table
and does it using a different connection. It's fine when it's done in
isolation (like at startup) but with Derby, when a transaction that creates
stuff gets executed, it causes a lock timeout because the two connections
are competing to set a value. To fix this I've set a little parameters (all
that time for a single line fix...) that forces the initialization when we
start the engine.

 * The HelloWorld process assignment was actually setting a variable that
wasn't structured properly when checking the message schema. I updated the
assignment.

So now we get the proper message in and out. I still have one last problem,
when the message gets back to Tuscany I get:

org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: local part cannot be "null" when
creating a QName
        at
org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
        at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
        at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
        at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
        at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
        at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103)
        at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
        at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
        at $Proxy5.hello(Unknown Source)
        at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)

The message looks fine to me, any idea what this could be? I've committed my
fixes so you should be able to reproduce it.

Cheers,
Matthieu

On Fri, May 30, 2008 at 11:39 PM, Matthieu Riou <matthieu@offthelip.org>
wrote:

> I've started looking at the DbError issue and reproduced it. Digging deeper
> it seems it's caused by a lock timeout in Derby on the
> OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
> deployed process. Here is an excerpt from the logs:
>
> DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
> http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1<http://tuscany.apache.org/implementation/bpel/example/helloworld%7DHelloWorld-1>(guid=hqejbhcnphr3beiwcxrx88)
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT t0.ID, t0.GUID,
> t0.PROCESS_ID, t0.PROCESS_TYPE, t0.VERSION FROM ODE_PROCESS t0 WHERE
> (t0.PROCESS_ID = ?)
> DEBUG - GeronimoLog.debug(66) | bound (1,{
> http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1<http://tuscany.apache.org/implementation/bpel/example/helloworld%7DHelloWorld-1>
> )
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
> OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
> DEBUG - GeronimoLog.debug(66) | bound (1,0)
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: INSERT INTO
> OPENJPA_SEQUENCE_TABLE (ID, SEQUENCE_VALUE) VALUES (?, ?)
> DEBUG - GeronimoLog.debug(66) | bound (2,1) (1,0)
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
> OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
> DEBUG - GeronimoLog.debug(66) | bound (1,0)
> WARN - GeronimoLog.warn(96) | connectionErrorOccurred called with null
> java.sql.SQLException: A lock could not be obtained within the time
> requested
>
> Right now I really have no clue why this is happening, there's no reason
> why a lock would get stuck on the OpenJPA sequence table. I have to dig
> deeper but it's getting late, I'll try to find more time during the week-end
> or Monday.
>
> Cheers,
> Matthieu
>
>
> On Fri, May 30, 2008 at 1:42 PM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> wrote:
>
>>
>>
>> -------- Original Message --------
>> Subject: Re: SCA BPEL - Problems with ODE - Help requested
>> Date: Fri, 30 May 2008 17:51:12 +0100
>> From: Mike Edwards <mike.edwards.inglenook@gmail.com>
>> To: tuscany-dev@ws.apache.org
>> References: <483EF8EC.5060509@gmail.com> <
>> fbdc6a970805291930v1dbb0e59hfc1b5f4a6e9809c1@mail.gmail.com>
>>
>> Matthieu Riou wrote:
>>
>>> On Thu, May 29, 2008 at 11:41 AM, Mike Edwards <
>>> mike.edwards.inglenook@gmail.com> wrote:
>>>
>>>  Folks,
>>>>
>>>> I've run into problems with the SCA BPEL implementation and the way it
>>>> interacts with the ODE engine - and I need help from some ODE experts,
>>>> please.
>>>>
>>>> OK, the SCA code is using the ODE engine in an embedded mode - and the
>>>> Tuscany code is trying to supply all the information and interfaces for
>>>> each
>>>> BPEL process to the ODE Engine - and in particular it aims to bypass the
>>>> ODE
>>>> database store so far as the BPEL process and its configuration are
>>>> concerned.
>>>>
>>>> So - Tuscany now has its own version of the ProcessConfImpl (I sent a
>>>> version of this out in a previous email).  One thing I discovered is
>>>> that it
>>>> is necessary for the Tuscany ProcessConfImpl to return "true" to the
>>>> isTransient() method. Otherwise, the ODE engine seems to try to find
>>>> information about the process in the database with nasty consequences
>>>> (failed transactions).
>>>>
>>>>
>>> Normally that shouldn't be a problem. Transient tells ODE to execute the
>>> process in memory but that only applies to short living processes, for
>>> most
>>> scenarios you'll want to have persistent executions. So we should try to
>>> see
>>> why these transactions fail.
>>>
>>>
>>>  HOWEVER, this has a side effect that is both curious and problematic.
>>>>
>>>> Using the ODE ProcessConfImpl (and by implication the database store for
>>>> the process itself), for a trivial "Hello World" BPEL process, when the
>>>> "hello" operation is invoked on the BPEL process, the ODE engine returns
>>>> the
>>>> result message as a "DeferredElementNSImpl" class with the name
>>>> "TestPart" -
>>>> which on inspection contains a child element "message" containing the
>>>> expected "Hello World" string.
>>>> (I attach the relevant part of the WSDL at the bottom)
>>>>
>>>>
>>>> When we switch to using the Tuscany ProcessConfImpl - with its
>>>> "transient"
>>>> setting, when we invoke the same process, we get back a different type
>>>> of
>>>> object - an "ElementImpl" named "TestPart".  This contains an
>>>> ElementNSImpl
>>>> object named "hello" containing a TextImpl child holding "Hello World".
>>>> This
>>>> structural layout is clearly different to the previous case - and is
>>>> wrong -
>>>> it isn't what is expected.
>>>>
>>>> Can anyone explain the difference in the two cases?  Any assistance
>>>> gratefully received.
>>>>
>>>>
>>> I don't see what could create this difference. The deferred element vs.
>>> normal element is nothing to worry about, it's just that the structure
>>> has
>>> already been traversed in one case because of the storage different, but
>>> the
>>> content itself should be identical. Usually the switch from transient to
>>> persistent doesn't bring that kind of differences but there's nothing I
>>> can
>>> think of off the top of my head that could create this behavior. The
>>> structural difference kind of reminds the difference between rpc and
>>> document style part wrappers but that shouldn't show here.
>>>
>>> So I'd like to reproduce this and see what's going wrong. Is all your
>>> code
>>> committed? Which test case are you using?
>>>
>>> Thanks,
>>> Matthieu
>>>
>>
>> Matthieu,
>>
>> Thanks for responding - let me try and pick my way through it for you:
>>
>> 1) All the code is committed and in the current Tuscany SVN.
>>
>> 2) The runtime code that is relevant is all in the implementation-bpel-ode
>> module
>>
>> 3) There are 3 sets of test/samples you can use to try things out:
>>
>> a) In Samples - helloworld-bpel  and   helloworld-bpel-ws
>> b) In Itest - there are 4 Itests under BPEL - helloworld
>>                                            - helloworld-reference
>>                                            - helloworld-ws
>>                                            - ping-pong
>>
>> I tend to use the 2 samples.  The second one uses web services and catches
>> the problems with the
>> data format returned by the BPEL process, for example. (You get an
>> exception in the databinding code
>> when it tries to transform it)
>>
>>
>> Now, I've fixed up the code in implementation-bpel-ode so that it works -
>> so the problems are all
>> masked.  But some simple commenting and uncommenting of lines of code can
>> reproduce all the problems.
>>
>> The 2 main classes to deal with are:
>>
>> - EmbeddedODEServer
>> - TuscanyProcessConfImpl
>>
>>
>> Currently, EmbeddedODEServer is set up to use the ODE Store and Persisted
>> BPEL Processes - the trick
>> I've done is that the code itself WRITES the deploy.xml file on the fly -
>> so that the programmer
>> does not need to write it.  This is handled by the BPELODEDeployFile
>> class.
>>
>> To change things, all you need to do is to go to the deploy(....) method
>> in EmbeddedOdeServer.  You
>> will find 2 blocks of code inside a try{} block - one for using the ODE
>> Store, the other for using
>> the Tuscany stuff without the store.  Simply comment out one an uncomment
>> the other to flip between
>> them.
>>
>> Only one other thing needs changing to work through all the problems - and
>> that is the response to
>> the isTransient() method of the TuscanyProcessConfImpl - currently it's
>> set to "true" - simply flip
>> it to return "false" to see the other behaviour.
>>
>>
>> One significant thing I discovered is that there is a "memory effect" in
>> the database.  IF the
>> database has been used ONCE by the ODE Store code then if the code is run
>> afterwards in "non Store"
>> mode, it works ok, with no transaction errors.  The transaction errors
>> only occur with a "virgin"
>> database that has never been used by the Store code.  If that ain't
>> confusing, nothing is...
>>
>> Note - running the Samples and Itests above using mvn usually cleans out
>> the DB - I've been able to
>> preserve the DB when running from Eclipse.
>>
>> When getting the transaction problem, my tracing showed that is happening
>> in:
>>
>> BpelProcess$HydrationLatch.doHydrate() line 755
>> "DbError"
>> "Unable to Commit"
>>
>>
>> Yours,  Mike.
>>
>>
>

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