[jira] Commented: (BEANUTILS-49) [beanutils] Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[
http://issues.apache.org/jira/browse/BEANUTILS-49?page=comments#action_12447974
]
Henri Yandell commented on BEANUTILS-49:
Niall - any opinion? Should we wontfix this and send it Struts-wards to be
fixed there?
[beanutils] Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: http://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-49) [beanutils] Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[
http://issues.apache.org/jira/browse/BEANUTILS-49?page=comments#action_12448025
]
Niall Pemberton commented on BEANUTILS-49:
--
I agree with Joe's comments, but we should review it here first to see if we
can find a solution. I'll try and find time to look at it
[beanutils] Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: http://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Assigned To: Niall Pemberton
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-49) [beanutils] Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[
http://issues.apache.org/jira/browse/BEANUTILS-49?page=comments#action_12448029
]
Kenneth Xu commented on BEANUTILS-49:
-
There is no doubt that Struts code should be changed to make best use of
beanutils. But I believe there is still some space for beanutils to improve too.
I think the getInstance is unnecessarily synchronized as the
beansByClassLoader.get is already synchronized. Futher, synchronize the entire
beansByClassLoader.get method seems to be overkill. As there is so much
existing code written to use the static methods in BeanUtils class, it's very
likely that the getInstance becomes hotspot in an heavy loaded application. So
developers would love to see every bit of performance gain in the getInstance
call.
[beanutils] Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: http://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Assigned To: Niall Pemberton
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
