[ 
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; 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to