cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [C3] Concurrency issues with ComponentProvider
Date Thu, 15 Mar 2012 02:25:47 GMT
On 03/14/2012 04:17 PM, Javier Puerto wrote:
> Thanks Steven
> El 14 de marzo de 2012 15:37, 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 to keep track 
of the issue.


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

View raw message