On 03/14/2012 04:17 PM, Javier Puerto wrote:
Thanks Steven
El 14 de marzo de 2012 15:37, Steven Dolg <steven.d...@indoqa.com
<mailto:steven.d...@indoqa.com>> 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/
