commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (BEANUTILS-49) Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Date Tue, 05 Dec 2006 01:33:22 GMT
    [ http://issues.apache.org/jira/browse/BEANUTILS-49?page=comments#action_12455493 ] 
            
Henri Yandell commented on BEANUTILS-49:
----------------------------------------

Gut thoughts.....

* We're improving the performance of something without having any numbers. So a bit iffy there.

* The code has calls to WeakHashMap.isEmpty with a comment that seems to indicate that this
is going to cause the weak references to be re-evaluated. I don't see how we can infer that
- in fact the javadoc for WeakHashMap would seem to imply that isEmpty does not re-evaluate
things. I got into looking at this out of worry that not synchronizing this 'purge' would
cause bugs.

* While we're here....  "} catch (SecurityException e) { /* SWALLOW - should we log this?
*/ }".   Should we? Should we throw an Exception? :) [yeah yeah, I know... change of API].

* Is the unset(ClassLoader) method meant to be public? Is the set(ClassLoader,Object) meant
to be private? The class looks designed for extension, should things be protected?





> 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


Mime
View raw message