cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: [C3] Concurrency issues with ComponentProvider
Date Wed, 14 Mar 2012 14:37:59 GMT
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


Mime
View raw message