Thanks Steven
El 14 de marzo de 2012 15:37, Steven Dolg <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).
>
> 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.
>
> 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.
>
> 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).
> Steven
>
Salu2
>
> 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
>>
>
>
