You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henri Yandell (JIRA)" <ji...@apache.org> on 2006/12/05 02:09:22 UTC
[jira] Updated: (BEANUTILS-49) Lock in
BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[ http://issues.apache.org/jira/browse/BEANUTILS-49?page=all ]
Henri Yandell updated BEANUTILS-49:
-----------------------------------
Attachment: BEANUTILS-49.patch
Improved version of the patch with the return statement back in, and a now incorrect comment removed.
> 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
> Affects Versions: 1.7.0
> Environment: Operating System: other
> Platform: Other
> Reporter: Jesper Richter-Reichhelm
> Assigned To: Niall Pemberton
> Fix For: 1.8.0
>
> Attachments: beanutils-49-ContextClassLoaderLocale.patch, BEANUTILS-49.patch
>
>
> 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; i<5; 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="col"><logic:iterate name="col" id="test"><logic:iterate
> name="col" id="test2"><logic:iterate name="col" id="test3"><logic:iterate
> name="col" id="test3"><logic:iterate name="col" id="test4"><logic: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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org