Re: 100% CPU Usage and blocking concurrent Threads when using t:saveState
I agree with Mario. It really seams llike the internal structure of the
TreeMap is destroyed, thus ending in some infinite loop and causing 100%
CPU.
Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
Regards,
Jakob Korherr
2009/12/10 Mario Ivankovits ma...@ops.co.at
For me, this clearly looks like concurrent usage of the request map.
All the servlet scopes (session, request, …) are not thread safe and one
has to assure that they are not accessed at the same time by multiple
threads.
This turns out to be hard as e.g. there is no standard how to synchronize
against the session map. As a side note: I often wonder why this does not
lead to much more problems in the wild …
Anyway, in your case it seems the internal datastructure of the request map
is damaged - which in fact is strange as I do not know when the request map
will be accessed by multiple threads.
Sorry that this is not a solution, but it should give you a clue where to
look next …
Ciao,
Mario
*Von:* Jan Baudisch [mailto:jan.baudi...@gmx.net]
*Gesendet:* Donnerstag, 10. Dezember 2009 08:02
*An:* MyFaces Discussion
*Betreff:* 100% CPU Usage and blocking concurrent Threads when using
t:saveState
Hello MyFaces Community,
we are using MyFaces 1.2.0 with Tomahawk Sandbox 1.1.5 and have the
problem, that once in a while we get 100% CPU Usage and blocking concurrent
threads because of using t:saveState
A thread dump shows that the threads always stops at
at java.util.TreeMap.put(TreeMap.java:545)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSaveStateBean(RedirectTrackerManager.java:306)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.resolveVariable(RedirectTrackerVariableResolver.java:50)
(The complete thread dump is attached). The problem shows up on one system
with heavy concurrent usage and JxBrowser as client.
After we kill these threads using Lambda Probe, the CPU Usage normalizes.
The problem occurs in that method:
...
public void addSaveStateBean(String expressionString, Object value)
{
if(log.isDebugEnabled())
log.debug(addSaveStateBean: + expressionString + value= +
value);
requestBeanMap.put(expressionString, value);
}
...
private final Map requestBeanMap = new TreeMap(); ...
As the problem is really severe for us, any hints are highly appreciated.
Many thanks in advance,
-- Jan
RE: 100% CPU Usage and blocking concurrent Threads when using t:saveState
Ja, a ConcurrentMap might do the trick, but the thing is, this is out of our
scope, isn't it?
These maps are create by the servlet container and thus are part of the servlet
spec. And even then, they are created by tomcat.
I am afraid, there is nothing we can do.
As far as I remember, there was about a discussion about synchronizing against
those map in the servelt container. But this has been abandoned for performance
reasons.
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] Im
Auftrag von Jakob Korherr
Gesendet: Donnerstag, 10. Dezember 2009 10:35
An: MyFaces Discussion
Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
t:saveState
I agree with Mario. It really seams llike the internal structure of the
TreeMap is destroyed, thus ending in some infinite loop and causing
100%
CPU.
Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
Regards,
Jakob Korherr
2009/12/10 Mario Ivankovits ma...@ops.co.at
For me, this clearly looks like concurrent usage of the request
map.
All the servlet scopes (session, request, …) are not thread safe and
one
has to assure that they are not accessed at the same time by multiple
threads.
This turns out to be hard as e.g. there is no standard how to
synchronize
against the session map. As a side note: I often wonder why this does
not
lead to much more problems in the wild …
Anyway, in your case it seems the internal datastructure of the
request map
is damaged - which in fact is strange as I do not know when the
request map
will be accessed by multiple threads.
Sorry that this is not a solution, but it should give you a clue
where to
look next …
Ciao,
Mario
*Von:* Jan Baudisch [mailto:jan.baudi...@gmx.net]
*Gesendet:* Donnerstag, 10. Dezember 2009 08:02
*An:* MyFaces Discussion
*Betreff:* 100% CPU Usage and blocking concurrent Threads when using
t:saveState
Hello MyFaces Community,
we are using MyFaces 1.2.0 with Tomahawk Sandbox 1.1.5 and have the
problem, that once in a while we get 100% CPU Usage and blocking
concurrent
threads because of using t:saveState
A thread dump shows that the threads always stops at
at java.util.TreeMap.put(TreeMap.java:545)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSav
eStateBean(RedirectTrackerManager.java:306)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolv
er.resolveVariable(RedirectTrackerVariableResolver.java:50)
(The complete thread dump is attached). The problem shows up on one
system
with heavy concurrent usage and JxBrowser as client.
After we kill these threads using Lambda Probe, the CPU Usage
normalizes.
The problem occurs in that method:
...
public void addSaveStateBean(String expressionString, Object
value)
{
if(log.isDebugEnabled())
log.debug(addSaveStateBean: + expressionString +
value= +
value);
requestBeanMap.put(expressionString, value);
}
...
private final Map requestBeanMap = new TreeMap(); ...
As the problem is really severe for us, any hints are highly
appreciated.
Many thanks in advance,
-- Jan
smime.p7s
Description: S/MIME cryptographic signature
Re: 100% CPU Usage and blocking concurrent Threads when using t:saveState
Hello Mario and Jakob,
thank you very much for your ideas on this problem.
As far as I understood, the map that is causing the trouble is initialized
inside class RedirectTrackerManager, and not by the application container:
protected Map getRequestBeanMap()
{
if (requestBeanMap == null)
{
requestBeanMap = new TreeMap();
}
return requestBeanMap;
}
so what do you think of using a concurrent counterpart of TreeMap instead, e.g.
java.util.concurrent.ConcurrentSkipListMap?
Best regards,
-- Jan
Am 10.12.2009 um 11:08 schrieb Mario Ivankovits:
Ja, a ConcurrentMap might do the trick, but the thing is, this is out of our
scope, isn't it?
These maps are create by the servlet container and thus are part of the
servlet spec. And even then, they are created by tomcat.
I am afraid, there is nothing we can do.
As far as I remember, there was about a discussion about synchronizing
against those map in the servelt container. But this has been abandoned for
performance reasons.
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] Im
Auftrag von Jakob Korherr
Gesendet: Donnerstag, 10. Dezember 2009 10:35
An: MyFaces Discussion
Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
t:saveState
I agree with Mario. It really seams llike the internal structure of the
TreeMap is destroyed, thus ending in some infinite loop and causing
100%
CPU.
Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
Regards,
Jakob Korherr
2009/12/10 Mario Ivankovits ma...@ops.co.at
For me, this clearly looks like concurrent usage of the request
map.
All the servlet scopes (session, request, …) are not thread safe and
one
has to assure that they are not accessed at the same time by multiple
threads.
This turns out to be hard as e.g. there is no standard how to
synchronize
against the session map. As a side note: I often wonder why this does
not
lead to much more problems in the wild …
Anyway, in your case it seems the internal datastructure of the
request map
is damaged - which in fact is strange as I do not know when the
request map
will be accessed by multiple threads.
Sorry that this is not a solution, but it should give you a clue
where to
look next …
Ciao,
Mario
*Von:* Jan Baudisch [mailto:jan.baudi...@gmx.net]
*Gesendet:* Donnerstag, 10. Dezember 2009 08:02
*An:* MyFaces Discussion
*Betreff:* 100% CPU Usage and blocking concurrent Threads when using
t:saveState
Hello MyFaces Community,
we are using MyFaces 1.2.0 with Tomahawk Sandbox 1.1.5 and have the
problem, that once in a while we get 100% CPU Usage and blocking
concurrent
threads because of using t:saveState
A thread dump shows that the threads always stops at
at java.util.TreeMap.put(TreeMap.java:545)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSav
eStateBean(RedirectTrackerManager.java:306)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolv
er.resolveVariable(RedirectTrackerVariableResolver.java:50)
(The complete thread dump is attached). The problem shows up on one
system
with heavy concurrent usage and JxBrowser as client.
After we kill these threads using Lambda Probe, the CPU Usage
normalizes.
The problem occurs in that method:
...
public void addSaveStateBean(String expressionString, Object
value)
{
if(log.isDebugEnabled())
log.debug(addSaveStateBean: + expressionString +
value= +
value);
requestBeanMap.put(expressionString, value);
}
...
private final Map requestBeanMap = new TreeMap(); ...
As the problem is really severe for us, any hints are highly
appreciated.
Many thanks in advance,
-- Jan
RE: 100% CPU Usage and blocking concurrent Threads when using t:saveState
Ah ... ok, sorry, didn't remember exactly. Ok, this changes things.
Yes, synchronizing in one way or the other might help here.
The ConcurrentSkipListMap is JDK 1.6 only, so might not make it as patch
into myfaces, but a simple synchronize() around each requestBeanMap access
might do the trick either. I do not suspect that you notice any performance
loss.
Please try and report back!
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: Jan Baudisch [mailto:jan.baudi...@gmx.net]
Gesendet: Donnerstag, 10. Dezember 2009 11:58
An: MyFaces Discussion
Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
t:saveState
Hello Mario and Jakob,
thank you very much for your ideas on this problem.
As far as I understood, the map that is causing the trouble is
initialized inside class RedirectTrackerManager, and not by the
application container:
protected Map getRequestBeanMap()
{
if (requestBeanMap == null)
{
requestBeanMap = new TreeMap();
}
return requestBeanMap;
}
so what do you think of using a concurrent counterpart of TreeMap
instead, e.g. java.util.concurrent.ConcurrentSkipListMap?
Best regards,
-- Jan
Am 10.12.2009 um 11:08 schrieb Mario Ivankovits:
Ja, a ConcurrentMap might do the trick, but the thing is, this is out
of our scope, isn't it?
These maps are create by the servlet container and thus are part of
the servlet spec. And even then, they are created by tomcat.
I am afraid, there is nothing we can do.
As far as I remember, there was about a discussion about
synchronizing against those map in the servelt container. But this has
been abandoned for performance reasons.
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] Im
Auftrag von Jakob Korherr
Gesendet: Donnerstag, 10. Dezember 2009 10:35
An: MyFaces Discussion
Betreff: Re: 100% CPU Usage and blocking concurrent Threads when
using
t:saveState
I agree with Mario. It really seams llike the internal structure of
the
TreeMap is destroyed, thus ending in some infinite loop and causing
100%
CPU.
Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
Regards,
Jakob Korherr
2009/12/10 Mario Ivankovits ma...@ops.co.at
For me, this clearly looks like concurrent usage of the request
map.
All the servlet scopes (session, request, …) are not thread safe
and
one
has to assure that they are not accessed at the same time by
multiple
threads.
This turns out to be hard as e.g. there is no standard how to
synchronize
against the session map. As a side note: I often wonder why this
does
not
lead to much more problems in the wild …
Anyway, in your case it seems the internal datastructure of the
request map
is damaged - which in fact is strange as I do not know when the
request map
will be accessed by multiple threads.
Sorry that this is not a solution, but it should give you a clue
where to
look next …
Ciao,
Mario
*Von:* Jan Baudisch [mailto:jan.baudi...@gmx.net]
*Gesendet:* Donnerstag, 10. Dezember 2009 08:02
*An:* MyFaces Discussion
*Betreff:* 100% CPU Usage and blocking concurrent Threads when
using
t:saveState
Hello MyFaces Community,
we are using MyFaces 1.2.0 with Tomahawk Sandbox 1.1.5 and have
the
problem, that once in a while we get 100% CPU Usage and blocking
concurrent
threads because of using t:saveState
A thread dump shows that the threads always stops at
at java.util.TreeMap.put(TreeMap.java:545)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSav
eStateBean(RedirectTrackerManager.java:306)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolv
er.resolveVariable(RedirectTrackerVariableResolver.java:50)
(The complete thread dump is attached). The problem shows up on one
system
with heavy concurrent usage and JxBrowser as client.
After we kill these threads using Lambda Probe, the CPU Usage
normalizes.
The problem occurs in that method:
...
public void addSaveStateBean(String expressionString, Object
value)
{
if(log.isDebugEnabled())
log.debug(addSaveStateBean: + expressionString +
value= +
value);
requestBeanMap.put(expressionString, value);
}
...
private final Map requestBeanMap = new TreeMap(); ...
As the problem is really severe for us, any hints are highly
appreciated.
Many thanks in advance,
-- Jan
really severe for us, any hints are highly
appreciated.
Many thanks in advance,
-- Jan
smime.p7s
Description: S/MIME cryptographic signature
RE: 100% CPU Usage and blocking concurrent Threads when using t:saveState
For me, this clearly looks like concurrent usage of the request map.
All the servlet scopes (session, request, …) are not thread safe and one has
to assure that they are not accessed at the same time by multiple threads.
This turns out to be hard as e.g. there is no standard how to synchronize
against the session map. As a side note: I often wonder why this does not
lead to much more problems in the wild …
Anyway, in your case it seems the internal datastructure of the request map
is damaged - which in fact is strange as I do not know when the request map
will be accessed by multiple threads.
Sorry that this is not a solution, but it should give you a clue where to
look next …
Ciao,
Mario
Von: Jan Baudisch [mailto:jan.baudi...@gmx.net]
Gesendet: Donnerstag, 10. Dezember 2009 08:02
An: MyFaces Discussion
Betreff: 100% CPU Usage and blocking concurrent Threads when using
t:saveState
Hello MyFaces Community,
we are using MyFaces 1.2.0 with Tomahawk Sandbox 1.1.5 and have the
problem, that once in a while we get 100% CPU Usage and blocking concurrent
threads because of using t:saveState
A thread dump shows that the threads always stops at
at java.util.TreeMap.put(TreeMap.java:545)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSaveStat
eBean(RedirectTrackerManager.java:306)
at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.re
solveVariable(RedirectTrackerVariableResolver.java:50)
(The complete thread dump is attached). The problem shows up on one system
with heavy concurrent usage and JxBrowser as client.
After we kill these threads using Lambda Probe, the CPU Usage normalizes.
The problem occurs in that method:
...
public void addSaveStateBean(String expressionString, Object value)
{
if(log.isDebugEnabled())
log.debug(addSaveStateBean: + expressionString + value= +
value);
requestBeanMap.put(expressionString, value);
}
...
private final Map requestBeanMap = new TreeMap(); ...
As the problem is really severe for us, any hints are highly appreciated.
Many thanks in advance,
-- Jan
smime.p7s
Description: S/MIME cryptographic signature
