Uploaded image for project: 'Commons BeanUtils'
  1. Commons BeanUtils
  2. BEANUTILS-49

Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.7.0
    • 1.8.0
    • Bean / Property Utils
    • None
    • Operating System: other
      Platform: Other

    • 37441

    Description

      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.

      Attachments

        1. BEANUTILS-49.patch
          6 kB
          Henri Yandell
        2. beanutils-49-ContextClassLoaderLocale.patch
          6 kB
          Niall Pemberton

        Activity

          People

            niallp Niall Pemberton
            jrichter Jesper Richter-Reichhelm
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: