Remi,
Your assessment is quite detailed and appears to be very thorough on
multiple levels.
Yes. JRebel adds it own class and many months ago I had a wild time
tracing an issue when the UrlBindingFactory singleton code was converted
to using an instance variable. Indeed this class exists in the JRebel
Stripes plug-in.
In addition, you are also correct JRebel is not to be used in Production
so this issue then becomes less critical and affects development
environments (which doesn't mean it isn't huge it just means you won't
be affected in production).
And as far as multiple threads are concerned... that could explain why
we don't see it as we use TestNG and disable parallel threads... not
because we want to but because we had some issues with singletons in
unit tests in the past.
As such, making a change to Stripes to increase synchronization is NOT
something that can be justified IMO.
But that is my 2 cents ;-)
Great assessment!
--Nikolaos
VANKEISBELCK Remi wrote:
Hi folks,
Just had a look, the stack seems to show some code that ain't in
Stripes (at least not in the 1.5.x branch at the time I write this
email). Found this in the stack trace :
net.sourceforge.stripes.controller.NameBasedActionResolverHelper.rescanFor
(NameBasedActionResolverHelper.java:217)
My guess is that you're using a modified action resolver (probably
from JRebel) which attempts to reload the beans while incoming
requests trigger bean class lookups at the same time. Hence the
concurrent modification exception : request handling thread is
iterating over UrlBindingFactory's classCache map at the same time
JRebel's action resolver changes the map content.
Stripes is supposed to scan for action beans once and only once,
before being ready to handle requests, so using unsynchronized maps
interlally in UrlBindingFactory is good design. Otoh, it doesn't offer
thread-safe action reload.
To fix the problem, we could synchronize access to the maps, or use
ConcurrentHashMap.
Yee (or anybody willing to see this fixed), you can demo the problem
by writing a unit test that accesses UrlBindingFactory concurrently
(via several threads). Then, you can fix by synchronizing where
appropriate. Last, we need to see what's the performance penalty.
IMHO this ain't a critical bug at all : stop using your browser while
JRebel does the reload and you won't have any exception, and anyway
JRebel ain't no production software as far as I know, so it's only a
minor hassle. Still, if you want to give it a shot : this would be a
better design that allow to write really reloadable action resolvers :P
Cheers
Remi
2011/2/11 samuel baudouin <osenseij...@gmail.com
<mailto:osenseij...@gmail.com>>
Hi all, Yee
>From your stack and your code, it seems that the problem comes from
one of the Stripes class...
When this exception occurs is it always at the same point? Is the
stack always the same?
While I never encountered the problem, here is a way that could
help you :
You could use a load tester program such as JMeter (don't forget to
make it share the session across the different virtual users).
It would probably not reproduce the problem but would certainly make
your life easy when testing with/without the different components.
On your IDE, you could then set up an exception breakpoint on that
ConcurrentModificationException and when raised pause the whole JVM
(ie pause all the threads -- see breakpoint properties in Eclipse).
>From here, you can see where the different threads are at, and
hopefully see where the double modifications is done.
You would probably need to have the sources of Stripes and JRebel
attached to your project (not in your project but just as a source
lookup for Eclipse) in order to browse to the different classes.
I know this is a bit of a bazooka to kill a fly, but this kind of
"random" exception could be particularly tricky to pin point.
If you have the time, the necessity, and most importantly not found a
work around, this is how you could go...
Regards,
Sam
On Fri, Feb 11, 2011 at 3:37 AM, Samuel Santos <sama...@gmail.com
<mailto:sama...@gmail.com>> wrote:
> Hi Yee and Nikolaos,
>
> We do not use JRebel and have come across the same issue several
times, so
> it's surely a Stripes issue.
> While we get the exception logged, it's transparent to the
client, the
> application does not crash and the client never sees an error.
> This issue is very rare and only happens when you open multiple
tabs at once
> as Yee pointed out.
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Thu, Feb 10, 2011 at 3:00 PM, Nikolaos Giannopoulos
> <nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
>>
>> Yee,
>>
>> Well then... turn off JRebel and attempt to reproduce the
bug... if you
>> can't then it isn't Stripes. Right?
>>
>> I know its tempting to keep JRebel engaged all the time and I
recall the
>> time I hit a bug in JRebel and thought it was one in Stripes...
it took
>> me a long time to consider simply turning off JRebel... but if you
>> already suspect JRebel then flip it off and attempt to reproduce.
>>
>> --Nikolaos
>>
>>
>>
>> Yee wrote:
>> > Hi Nokolaos,
>> >
>> > The bug has already been reported to JRebel. Stripes plugin
for JRebel
>> > was
>> > created by third party, so it could take a while for it to be
fixed.
>> >
>> > My concern here is to ascertain whether
ConcurrentModificationException
>> > error is
>> > a bug in Stripes - or caused by the bug in JRebel.
>> >
>> > Cheers,
>> > Yee
>> >
>> >
>> >
>> >
>> >
>> >
------------------------------------------------------------------------------
>> > The ultimate all-in-one performance toolkit: Intel(R)
Parallel Studio
>> > XE:
>> > Pinpoint memory and threading errors before they happen.
>> > Find and fix more than 250 security defects in the
development cycle.
>> > Locate bottlenecks in serial and parallel code that limit
performance.
>> > http://p.sf.net/sfu/intel-dev2devfeb
>> > _______________________________________________
>> > Stripes-users mailing list
>> > Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
>> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>> >
>> >
>>
>>
>>
>>
------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel
Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development
cycle.
>> Locate bottlenecks in serial and parallel code that limit
performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel
Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development
cycle.
> Locate bottlenecks in serial and parallel code that limit
performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Samuel Baudouin
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel
Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
