Re: [Stripes-users] Still seeing ConcurrentModificationException

[VANKEISBELCK Remi]

Hi Nikolaos, folks,

Ah, the reloadable Action Resolver, I knew it.

I guess they have the same issues with hibernate, spring, and all these
stateful frameworks. Must be quite a challenge to have a fully reloadable
JEE app these days !! Statefulness...

Anyway, I agree that trying to sync just for that is quite useless, and
risky. I've learnt that threading is always more complex that you think...

Maybe it should just be part of the JRebel/Stripes docs ? I mean, I don't
use JRebel myself (nor any other reloadable action resolver btw, even if the
idea is quite cool - who said hot-deployed groovy beans ???) so I'm not
concerned, but apparently it caused a few headaches to some of you !

Cheers

Remi


2011/2/12 Nikolaos Giannopoulos 

>  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 
>
>> 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  wrote:
>

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Nikolaos Giannopoulos]

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 >


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 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
> 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 kn

Re: [Stripes-users] Still seeing ConcurrentModificationException

[VANKEISBELCK Remi]

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 

> 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  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
> >  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
> >> > 

Re: [Stripes-users] Still seeing ConcurrentModificationException

[samuel baudouin]

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  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
>  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
>> > 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
>
>
> --
> 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
>
>



-- 
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 

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Samuel Santos]

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> 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
> > 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
>
--
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

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Nikolaos Giannopoulos]

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
> 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

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Yee]

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
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Nikolaos Giannopoulos]

Yee,

If you definitely suspect a bug in JRebel then post to their forums.  I 
have had great results / turn around (no pun intended) by the support 
team and they have gone as far as tweaking JRebel to resolve issues I 
reported in the past.

I am using JRebel 3.1.2a with MyEclipse 8.6 and I have no issues with 
Stripes 1.5.x (.3+).

--Nikolaos



Yee wrote:
> I figured out how to reproduce the error.
>
> With JRebel's Stripes plugin enabled test.jsp takes some 1 minute to load. 
> While
> waiting for it to load, I open another browser tab and do a bit of browsing
> around. That would trigger the error about 50% of the time.
>
> Sometime the error will be with test.jsp, sometime the error will occur at the
> other page that I was browsing.
>
> There is a bug in JRebel definitely. But I am not sure whether the JRebel bug 
> is
> causing the ConcurrentModificationException - or it is causing a bug in 
> Stripes
> to surface.
>
> I am using the Eclipse Helios SR1. JRebel plugin was updated to the most 
> recent
> version.
>
> Cheers,
> Yee
>
>
> Below is the stack trace (with test.jsp).
>
> Feb 10, 2011 2:00:21 PM org.apache.catalina.core.ApplicationDispatcher invoke
> SEVERE: Servlet.service() for servlet jsp threw exception
> java.util.ConcurrentModificationException
>   at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136)
>   at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131)
>   at 
> net.sourceforge.stripes.controller.UrlBindingFactory.getBindingPrototype(Url
> BindingFactory.java:132)
>   at 
> net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getUrlBindin
> gFromPath(AnnotatedClassActionResolver.java:198)
>   at 
> net.sourceforge.stripes.tag.FormTag.getActionBeanUrlBinding(FormTag.java:100
> )
>   at net.sourceforge.stripes.tag.FormTag.getActionBean(FormTag.java:376)
>   at 
> net.sourceforge.stripes.tag.InputTagSupport.getActionBean(InputTagSupport.ja
> va:392)
>   at 
> net.sourceforge.stripes.tag.InputTagSupport.loadErrors(InputTagSupport.java:
> 350)
>   at 
> net.sourceforge.stripes.tag.InputTagSupport.getFieldErrors(InputTagSupport.j
> ava:366)
>   at 
> net.sourceforge.stripes.tag.InputTagSupport.doStartTag(InputTagSupport.java:
> 409)
>   at 
> net.sourceforge.stripes.tag.InputOptionsCollectionTag.doEndTag(InputOptionsC
> ollectionTag.java:322)
>   at 
> org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005foptions
> _002dcollection_005f0(test_jsp.java:229)
>   at 
> org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005fselect_
> 005f0(test_jsp.java:187)
>   at 
> org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005fform_00
> 5f0(test_jsp.java:136)
>   at 
> org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspService(test_jsp.java:94)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>   at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3
> 86)
>   at 
> org.apache.jasper.servlet.JspServlet._serviceJspFile(JspServlet.java:313)
>   at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java)
>   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:206)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
> java:646)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDis
> patcher.java:436)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
> er.java:374)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
> .java:302)
>   at 
> net.sourceforge.stripes.action.ForwardResolution.execute(ForwardResolution.j
> ava:110)
>   at 
> net.sourceforge.stripes.controller.DispatcherHelper$7.intercept(DispatcherHe
> lper.java:508)
>   at 
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext
> .java:158)
>   at 
> net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept(HttpCacheI
> nterceptor.java:99)
>   at 
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext
> .java:155)
>   at 
> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(Be
> foreAfterMethodInterceptor.java:113)
>   at 
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext
> .java:155)
>   at 
> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.ja
> va:74)
>   at 
> ne

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Yee]

I figured out how to reproduce the error.

With JRebel's Stripes plugin enabled test.jsp takes some 1 minute to load. While
waiting for it to load, I open another browser tab and do a bit of browsing
around. That would trigger the error about 50% of the time.

Sometime the error will be with test.jsp, sometime the error will occur at the
other page that I was browsing.

There is a bug in JRebel definitely. But I am not sure whether the JRebel bug is
causing the ConcurrentModificationException - or it is causing a bug in Stripes
to surface.

I am using the Eclipse Helios SR1. JRebel plugin was updated to the most recent
version.

Cheers,
Yee


Below is the stack trace (with test.jsp).

Feb 10, 2011 2:00:21 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.util.ConcurrentModificationException
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131)
at 
net.sourceforge.stripes.controller.UrlBindingFactory.getBindingPrototype(Url
BindingFactory.java:132)
at 
net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getUrlBindin
gFromPath(AnnotatedClassActionResolver.java:198)
at 
net.sourceforge.stripes.tag.FormTag.getActionBeanUrlBinding(FormTag.java:100
)
at net.sourceforge.stripes.tag.FormTag.getActionBean(FormTag.java:376)
at 
net.sourceforge.stripes.tag.InputTagSupport.getActionBean(InputTagSupport.ja
va:392)
at 
net.sourceforge.stripes.tag.InputTagSupport.loadErrors(InputTagSupport.java:
350)
at 
net.sourceforge.stripes.tag.InputTagSupport.getFieldErrors(InputTagSupport.j
ava:366)
at 
net.sourceforge.stripes.tag.InputTagSupport.doStartTag(InputTagSupport.java:
409)
at 
net.sourceforge.stripes.tag.InputOptionsCollectionTag.doEndTag(InputOptionsC
ollectionTag.java:322)
at 
org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005foptions
_002dcollection_005f0(test_jsp.java:229)
at 
org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005fselect_
005f0(test_jsp.java:187)
at 
org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005fform_00
5f0(test_jsp.java:136)
at 
org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspService(test_jsp.java:94)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3
86)
at 
org.apache.jasper.servlet.JspServlet._serviceJspFile(JspServlet.java:313)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:206)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:646)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDis
patcher.java:436)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
er.java:374)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
.java:302)
at 
net.sourceforge.stripes.action.ForwardResolution.execute(ForwardResolution.j
ava:110)
at 
net.sourceforge.stripes.controller.DispatcherHelper$7.intercept(DispatcherHe
lper.java:508)
at 
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext
.java:158)
at 
net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept(HttpCacheI
nterceptor.java:99)
at 
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext
.java:155)
at 
net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(Be
foreAfterMethodInterceptor.java:113)
at 
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext
.java:155)
at 
net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.ja
va:74)
at 
net.sourceforge.stripes.controller.DispatcherHelper.executeResolution(Dispat
cherHelper.java:502)
at 
net.sourceforge.stripes.controller.DispatcherServlet.executeResolution(Dispa
tcherServlet.java:286)
at 
net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServl
et.java:170)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:290)
at 
org.apache.catalina.c

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Yee]

I managed to isolate the isolate the JRebel error - but I could not establish
that JRebel is the cause of the ConcurrentModificationException.

I will post the full stacktrace when I see the problem again, but that could be
a long wait.

It looks like I am the only one seeing this error. So I am keeping my finger
cross that it won't manifest in the production server.

For those who are interested, below is the cause of the JRebel error.

JSP:

  

  


ActionBean:
@UrlBinding("/test.action")
public class TestActionBean extends UserProfileBaseActionBean
{
  @DefaultHandler
  public Resolution view() {
List timeZoneList = TimeZoneSelect.getTimeZoneList();

getContext().getRequest().setAttribute("timeZoneList", timeZoneList);
return new ForwardResolution("/jsp/test.jsp");
  }
}


Util Class:
/**
 * This class is a container for associating a TimeZone with a long description
to facilitate dropdown
 * selection of Time Zones.
 * 
 * This class provides static method {@code getTimeZoneList} which returns a
list of statically constructed
 * TimeZoneSelect objects.
 * 
 * @author yee
 */
public class TimeZoneSelect
{
  TimeZone timeZone;
  String tzName;
  String description;

  public TimeZoneSelect(TimeZone timeZone, String description, String tzName) {
this.timeZone = timeZone;
this.description = description;
this.tzName = tzName;
  }

  static List tzlist = new ArrayList();

  static {
String[] timeZoneIds = TimeZone.getAvailableIDs();
Date date11 = new Date();
for (int i = 0; i < timeZoneIds.length; i++) {
  TimeZone timezone = TimeZone.getTimeZone(timeZoneIds[i]);
  String tzName = 
timezone.getDisplayName(timezone.inDaylightTime(date11),
TimeZone.LONG);
  String description = (timezone.getRawOffset() < 0 ? "GMT " : "GMT +")
+ new DecimalFormat("00").format(timezone.getRawOffset() / (60 * 60 
*
1000)) + ":"
+ new DecimalFormat("00").format(Math.abs(timezone.getRawOffset() / 
(60 *
1000)) % 60)
+ " | " + timezone.getID() + " [" + tzName + "]";

  tzlist.add(new TimeZoneSelect(timezone, description, tzName));
}
  }

  public static List getTimeZoneList() {
return tzlist;
  }

//accessor methods omitted.



--
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

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Nikolaos Giannopoulos]

Yee,

If you want people to help you need to give as much information as 
possible to pin-point your problem.

The full stack trace would be a great start. As well, the JSP code and 
if you could strip it down to a minimal case that reproduces the issue 
that would be even more ideal. You'll also need to specify the JRebel 
plugins you use.

As far as JRebel and 1.5.5 is concerned I use both and have no issues.

You'll need to go deeper if you expect any help.

--Nikolaos




Yee wrote:
> For one thing - jRebel's Stripes plugin was having working with Stripes 1.5.5.
> One particular jsp is causing jRebel to scan some resources 1000+ times,
> resulting in extremely slow load time. 
>
> I am wondering that could be the cause of the ConcurrentModificationException 
> as
> well. I only see the problem very occasionally so it is hard to pin it down.
>
> Is anybody seeing this problem?
>
>
>
>
> --
> 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
>
>   


--
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

Re: [Stripes-users] Still seeing ConcurrentModificationException

[Yee]

For one thing - jRebel's Stripes plugin was having working with Stripes 1.5.5.
One particular jsp is causing jRebel to scan some resources 1000+ times,
resulting in extremely slow load time. 

I am wondering that could be the cause of the ConcurrentModificationException as
well. I only see the problem very occasionally so it is hard to pin it down.

Is anybody seeing this problem?




--
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

[Stripes-users] Still seeing ConcurrentModificationException

[Yee]

Hi,

I am using stripes 1.5.5 - but I am seeing ConcurrentModificationExcepiton.

I thought it is already fixed a couple version back?

Stacktrace attached below.

Regards,
Yee

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at
net.sourceforge.stripes.controller.UrlBindingFactory.addBinding
(UrlBindingFactory.java:349)
at
net.sourceforge.stripes.controller.UrlBindingFactory.getBindingPrototype
(UrlBindingFactory.java)
at
net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getUrlBinding
(AnnotatedClassActionResolver.java:212)
at
net.sourceforge.stripes.controller.NameBasedActionResolver.getUrlBinding
(NameBasedActionResolver.java:139)
at
net.sourceforge.stripes.controller.NameBasedActionResolverHelper.rescanFor
(NameBasedActionResolverHelper.java:217)
at
net.sourceforge.stripes.controller.NameBasedActionResolverHelper
.getActionBeanType(NameBasedActionResolverHelper.java:189)
at
net.sourceforge.stripes.controller.NameBasedActionResolver.getActionBeanType
(NameBasedActionResolver.java)
at
net.sourceforge.stripes.util.UrlBuilder.getValidationMetadata
(UrlBuilder.java:373)
at net.sourceforge.stripes.util.UrlBuilder.build(UrlBuilder.java:403)
at net.sourceforge.stripes.util.UrlBuilder.toString(UrlBuilder.java:304)
at net.sourceforge.stripes.tag.FormTag.buildAction(FormTag.java:509)
at net.sourceforge.stripes.tag.FormTag.doEndTag(FormTag.java:239)
at
org.apache.jsp.WEB_002dINF.jsp.private_.inc_005ffrontTabPanel_jsp._jspService
(inc_005ffrontTabPanel_jsp.java:418)
at org.apache.jasper.runtime.HttpJspBase.service
(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:386)
at 
org.apache.jasper.servlet.JspServlet._serviceJspFile(JspServlet.java:313)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest
(ApplicationDispatcher.java:436)
at
org.apache.catalina.core.ApplicationDispatcher.doForward
(ApplicationDispatcher.java:374)
at
org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:302)
at
net.sourceforge.stripes.action.ForwardResolution.execute
(ForwardResolution.java:110)
at
net.sourceforge.stripes.controller.DispatcherHelper$7.intercept
(DispatcherHelper.java:508)
at
net.sourceforge.stripes.controller.ExecutionContext.proceed
(ExecutionContext.java:158)
at
net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept
(HttpCacheInterceptor.java:99)
at
net.sourceforge.stripes.controller.ExecutionContext.proceed
(ExecutionContext.java:155)
at
net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept
(BeforeAfterMethodInterceptor.java:113)
at
net.sourceforge.stripes.controller.ExecutionContext.proceed
(ExecutionContext.java:155)
at
net.sourceforge.stripes.controller.ExecutionContext.wrap
(ExecutionContext.java:74)
at
net.sourceforge.stripes.controller.DispatcherHelper.executeResolution
(DispatcherHelper.java:502)
at
net.sourceforge.stripes.controller.DispatcherServlet.executeResolution
(DispatcherServlet.java:286)
at
net.sourceforge.stripes.controller.DispatcherServlet.service
(DispatcherServlet.java:170)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at
net.sourceforge.stripes.controller.StripesFilter.doFilter
(StripesFilter.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)



--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sf