[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tuscany-user
Subject:    Re: Problem with serializing shared resources over RMI binding
From:       Simon Laws <simonslaws () googlemail ! com>
Date:       2011-05-09 9:38:34
Message-ID: BANLkTimymF7afPZO4Fr0hrFbH_i920nQiQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, May 3, 2011 at 3:36 PM, Millies, Sebastian
<Sebastian.Millies@ids-scheer.com> wrote:
>
>> -----Original Message-----
>> From: Simon Laws [mailto:simonslaws@googlemail.com]
>> Sent: Tuesday, May 03, 2011 3:16 PM
>> To: user@tuscany.apache.org
>> Subject: Re: default binding for local service: serialization question
>>
>> On Tue, May 3, 2011 at 1:43 PM, Millies, Sebastian
>> <Sebastian.Millies@ids-scheer.com> wrote:
>> >> -----Original Message-----
>> >> From: Simon Laws [mailto:simonslaws@googlemail.com]
>> >> Sent: Tuesday, May 03, 2011 2:16 PM
>> >> To: user@tuscany.apache.org
>> >> Subject: Re: default binding for local service: serialization
>> question
>> >>
>> >> On Tue, May 3, 2011 at 11:33 AM, Millies, Sebastian
>> >> <Sebastian.Millies@ids-scheer.com> wrote:
>> >> > Hello there,
>> >> >
>> >> >
>> >> >
>> >> > I have a very basic question about local interfaces:
>> >> >
>> >> > does Tuscany require parameters passed over a local service
>> interface to be
>> >> > Serializable?
>
> [snip]
>
>> > Your answer has confirmed my ruling out one potential cause. I guess
>> I will now
>> > concentrate on the remote calls: I suspect there may be a problem
>> with the following
>> > situation:
>> >
>> >   @Reference
>> >   remoteProxy ...
>> >
>> >   private Serializable instanceVariable = ...
>> >
>> >   private void callService( Serializable localVariable )       {
>> >     remoteProxy.serviceMethod( instanceVariable, localVariable )
>> >   }
>> >
>> > where many concurrent threads try serializing (externalizing?) the
>> shared instanceVariable
>> > simultaneously.
>
> [snip]
>
>>
>> Yes, in the remotable case it will serialize. What's the error you're
>> seeing?
>>
>> Simon
>
> Note: I have changed the subject, because we are no longer dealing with
> a local service invocation. Also, the example that follows does not use
> binding.sca but an RMI binding.
>
> To answer your question first: I am seeing a ClassCastException.
>
> I have finally succeeded in creating a test case for this, which I suspect
> may be a bug in Tuscany 1.6. I attach a zip archive containing an Eclipse
> project with the example.
>
> Instructions to recreate the problem:
> 1. run server.ServerLauncher
> 2. run client.ClientLauncher
> 3. In order to confirm that everything started correctly, perform unit test
>   tester.ClientTest
> 4. Note the inline comments in client.ClientImpl and perform a test under
>   heavy load
>
> If you are using JMeter, you can modify the Export2JMeter.jardesc to export
> the project classes to your JMeter lib/ext. You may then use the test plan
> provided as resources/TestplanClient.jmx. On my machine it suffices to have
> 500 threads in 5 seconds with 2 repeats in order to produce the exception.
>
> For completeness, I also attach a text file with the full stack trace.
>
> The exception goes away when you modify ClientImpl to pass a fresh
> ExecutionContext  (local variable) to the Server in each service invocation.
>
> Thanks for looking into this. Can you confirm its a bug? Or is it my mistake,
> passing a shared resource as a service argument?
>
> -- Sebastian
>
>
>
>
>
Hi Sebastian

I tried your test over the weekend and I can at least confirm I see
the same issue that you're seeing. I don't have a good answer for it
though. Looking at the stack trace it's failing on a class cast. A bit
further up the stack I stopped it in the SDO class HelperProviderBase
in this method

    protected void writeDataObject(DataObject dataObject, ObjectOutput
objectOutput) throws IOException
    {
      DataGraph dataGraph = dataObject.getDataGraph();
      if (dataGraph != null)
      {
        objectOutput.writeByte(0);
        objectOutput.writeUTF(SDOUtil.getXPath(dataObject));
        objectOutput.writeObject(dataGraph);
      }
      else if (dataObject.getContainer() != null)
      {
        objectOutput.writeByte(0);
        objectOutput.writeUTF(SDOUtil.getXPath(dataObject));
        objectOutput.writeObject(dataObject.getRootObject());
      }
      else
      {

With single, non-threaded calls, it doesn't hit either of these ifs.
As you ramp up the thread count if goes into the
dataObject.getContainer() clause. I think the container is related to
emf so it looks like something in sdo or emf is not thread safe.

It all gets a bit murky for me at this point as I don't know much
about sdo. Any sdo/emf experts out there for which this rings a bell?

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

[prev in list] [next in list] [prev in thread] [next in thread]