|
»
« Return to Thread: [C3] Concurrency issues with ComponentProvider
Re: [C3] Concurrency issues with ComponentProvider
by Steven Dolg-2
::
Rate this Message:
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
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
« Return to Thread: [C3] Concurrency issues with ComponentProvider
| Free embeddable forum powered by Nabble | Forum Help |
