Re: [C3] Concurrency issues with ComponentProvider

On 03/14/2012 04:17 PM, Javier Puerto wrote:

Thanks Steven

El 14 de marzo de 2012 15:37, Steven Dolg <steven.dolg@...> escribió:

Hi Javier,

that's the first time, I've heard of concurrency issues in C3.
That's not to say there cannot be any, just that it's probably a rare case or you're stressing the system more than anyone else has yet.

Strange, we experienced this kind of problems since the beginning. For your information,
we need 34 request to retrieve all the resources for the homepage (devel environment).

I can confirm Javier's observations, we are colleagues and on the same project. Further we experience some random exceptions in our c3 REST services, like said random.  Javier has a nose to track down concurrency issues (see latest c2.2 patch) and uses the force of jmeter. ;)

...but even without jmeter we experience this strange behaviour.

 

Some thoughts top off my head:
- providers and factories should be singletons, as they should not have any state (ie. member variables)
- the invocation must be a prototype, as it has a state
- if "synchronized" reliably fixes the problem, then there is a problem with accessing the same, stateful resource from different threads

Yeah, I didn't investigate further but maybe the problem is only for certain factory.
 

Hmm, when Javier showed me the patch before submitting I raised my eyebrows of the sync use in the methods, but I can confirm applying the patch has fixed the weird image switching behaviour.

so I agree with Steve saying "if "synchronized" reliably fixes the problem, then there is a problem with accessing the same, stateful resource from different threads" but actually it is the access of the underlying spring appcontext since nearly all factories are using it to resolve the components. Meaning the access of the spring bean factory seems not be in general "synchronized".

I cannot look into this right now, but I'll sure do this evening.
Are you using trunk or a certain build?

We are using trunk.
 

It would be really nice to get some feedback on this since see above we experience some general glitches in our app which could be provoked by concurrency issues

I might be able to reproduce this on my own, but a reduced version (ie a controller and sitemap) for your setup would certainly help.

I could provide an example block but I don't know if I will have time till next weekend. Here is how we declared the static resources in sitemap:

    <map:pipeline id="static-resources" type="noncaching">
<!--       <map:parameter name="cache-expires" value="access plus 1 weeks"/> -->
     
      <!-- images -->
      <map:match pattern="images/**">
        <map:match pattern="**.*">
          <map:read src="resources/{map:1}.{map:2}" />
        </map:match>
      </map:match>
     
      <!-- css and js -->
      <map:match pattern="**.*">
        <map:read src="resources/{map:1}.{map:2}" />
      </map:match>
     
    </map:pipeline>

I can confirm that the HTML page is well-formed (JMeter tests again) and the problem is in Cocoon side (see FileReader patch for my tests). So to reproduce the problem, a page with 30 <img/> tags loading different images should work and refresh sometimes without cache (ctrl+f5 in FF).

I think the key is the <map:match pattern="**.*"> which is a welcome door for concurrency issues. You need to request the page around 10 times and you see image glitches.

I started a small testing project but will need to finish it later. BTW I created https://issues.apache.org/jira/browse/COCOON3-93 to keep track of the issue.

salu2

-- 
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/