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 21:23:45 GMT
On Thu, Jun 5, 2008 at 12:38 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:

> Matthieu,
>
> First - many thanks for your hard work on this.
>
> I take no pleasure in saying this, but I am glad that the DB problem was
> ODE's problem rather than Tuscany's - it looks like you are far more
> experienced in handling that area of code!
>
> Regarding that remaining error, which is generated by Tuscany.  I am
> assuming that this is the same error that I examined previously when using
> the TuscanyProcessConfImpl rather than the ODE ProcessConfImpl - namely that
> the returned data structure from ODE is simply different - and I believe it
> is in error - as the top level element is of a different type: - quoting
> from my previous email, in the case of using the TuscanyProcessConfImpl:
>

Actually I think it's a different problem even if the symptom looks
identical (as I mentioned, I fixed the process). First, it always break in
the same way, whether the process is transient or not (which is reassuring).
Second, the message looks good to me this time:

>>>Response:
<?xml version="1.0" encoding="UTF-8"?>
<message><TestPart><hello xmlns="
http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl"><message>Hello
World</message></hello></TestPart></message>

The namespaces of the <hello> and the <message> elements seem correct. Don't
you think?

Cheers,
Matthieu



>
>
> "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."
>
> To explain futher, the direct cause of that exception you list is the fact
> that the top level element returned - the ElementImpl - does NOT have a
> namespace declared (I believe that it should be an ElementNSImpl) - and it
> is the lack of the NS that is at the root of the "null" exception that
> Tuscany returns.  I note that this is NOT the same data structure that is
> returned by ODE when the ODE ProcessConfImpl is used - that data structure
> IS headed by a DeferredElementNSImpl (the deferred aspect isn't important,
> but the "NS" aspect very much is important).
>
> I could not determine why there was this difference in the data structure
> returned.  I'll have another check using your fixed version of the code -
> but it would be useful if you could give me a clue about where in the ODE
> code this data element is being generated - it is very hard to trace.
>
>
>
> Yours,  Mike.
>
> PS - I assume that I need to take a latest build from the ODE SVN to get
> your fixes for the DB problem?
>
>
> Matthieu Riou wrote:
>
>> 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>
>>> <
>>> 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>
>>> <
>>> 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