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.
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
I cannot look into this right now, but I'll sure do this evening.
Are you using trunk or a certain build?
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.
Steven
Am 14.03.2012 13:55, schrieb Javier Puerto:
Hi Cocoon developers,
we are working in a project based on C3 and we found a strange
behaviour when loading the static resources. We are developing a Web
2.0 application and therefore we have a lot of resources (js, images
and css). The weird thing is that sometimes the system is returning
the wrong resources, returning a js instead of a css or switching
images...
For my tests I did a little modification in class FileReaderComponent
to see the source of the file that is being served. See attached file
"FileReaderComponent.diff".
This modification uses System.out to show the source of the file
before and after read it. The component seems to be fine, also it's
very simple so it seems to not be the cause. The patch allow me to
discard the component as cause of problem, the source passed as
argument when there's too much resources requests are wrong sometimes.
I've review how the components are instantiated and I saw a possible
design problem for ComponentProvider class.
<bean name="org.apache.cocoon.sitemap.ComponentProvider"
class="org.apache.cocoon.sitemap.SpringComponentProvider">
<property name="actionFactory"
ref="org.apache.cocoon.sitemap.spring.ActionFactory" />
<property name="languageInterpreterFactory"
ref="org.apache.cocoon.sitemap.expression.LanguageInterpreterFactory" />
<property name="pipelineComponentFactory"
ref="org.apache.cocoon.sitemap.spring.PipelineComponentFactory" />
<property name="pipelineFactory"
ref="org.apache.cocoon.sitemap.spring.PipelineFactory" />
</bean>
<bean name="org.apache.cocoon.sitemap.Invocation"
class="org.apache.cocoon.sitemap.InvocationImpl" scope="prototype">
<property name="componentProvider"
ref="org.apache.cocoon.sitemap.ComponentProvider" />
</bean>
Above is the sitemap component configuration, the InvocationImpl is
the component that will create the different components thought the
ComponentProvider that will delegate on different factories. The
problem I see is that while the Invocation is declared as "prototype",
the ComponentProvider is a shared instance so it could be that on high
demand the methods overlaps between request. I've solved the problem
declaring the methods as "synchronized" (att.
SpringComponentProvider.diff).
This will solve the problems with concurrency, but I wonder if it's
the best solution. WDYT?
It's very hard to reproduce the problem with tools like JMeter (better
reloading directly in browser). Anyways it's happend sometimes with my
current functional test plan but I can't reproduce it consistently.
Also the JMeter test plan is designed for our current web project so I
can't attach it. The functional tests is configure as:
* 30 threads
* No delay between request
* Ramp up 1s
* Infinite loop
* Random controller with 6 static requests, each request with size
assertion.
Please, tell me if you need more detailed tests or it's enough. IMO
anybody could see the problem if there's a lot of concurrent resources
involved.
Salu2
