commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37441] New: - Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Date Thu, 10 Nov 2005 09:38:23 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37441>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37441

           Summary: Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: major
          Priority: P2
         Component: Bean Utilities
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: jrichter@jamba.net


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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message