The bug report can be found at http://issues.apache.org/bugzilla/show_bug.cgi?id=37441 .
> -----Ursprüngliche Nachricht----- > Von: Joe Germuska [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 10. November 2005 11:22 > An: Richter-Reichhelm, Jesper; Struts Users Mailing List > Betreff: Re: AW: Lock in > BeanUtilsBean.getInstance(BeanUtilsBean.java:78) > > Jesper: > > I'm glad you found a workaround works for you -- but if you have a > minute could you file a ticket in Bugzilla noting the issue (and the > workaround)? http://issues.apache.org/bugzilla/ > > It should be possible to make some changes to Struts to eliminate or > minimize calls to the static synchronized method. If you put this in > Bugzilla, it will help keep it on the radar as something which needs > fixing. > > Thanks > Joe > > At 11:06 AM +0100 11/10/05, Richter-Reichhelm, Jesper wrote: > >We've found a workaround ourselves: > >We've now using Commons Beanutils 1.6.1 which does not contain the > >classes BeanUtilsBeans and PropertyUtilsBean. > >So far this works fine with Struts 1.2.7. > > > >Ciao, > >Jesper Richter-Reichhelm > > > >> After switching to Struts 1.2.7 (and Commons Beanutils 1.7) we > >> experience problems with Struts Tags' usage of > >> PropertyUtils.getProperty() to read a bean's property value: > >> During high > >> traffic time threads begin to wait at the synchronized method > >> org.apache.commons.beanutils.BeanUtilsBean.getInstance() > which causes > >> the complete Thread pool to be used up (all 70 threads in our live > >> configuration). > >> > >> The locked threads all look like this: > >> "ExecuteThread: '16' for queue: 'weblogic.kernel.Default'" > >> daemon prio=5 > >> tid=0x013cc9b8 nid=0x1c waiting for monitor entry > [8fb7e000..8fb7fc28] > >> at > >> org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUti > >> lsBean.jav > >> a:78) > >> - waiting to lock <0xf67320c0> (a java.lang.Class) > >> at > >> org.apache.commons.beanutils.PropertyUtilsBean.getInstance(Pro > >> pertyUtils > >> Bean.java:101) > >> at > >> org.apache.commons.beanutils.PropertyUtils.getProperty(Propert > >> yUtils.jav > >> a:290) > >> at > >> org.apache.struts.taglib.logic.CompareTagBase.condition(Compar > >> eTagBase.j > >> ava:183) > >> at > >> > org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:46) > >> at > >> org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(C > >> onditional > >> TagBase.java:174) > >> at > >> > jsp_servlet._sounds._ringtones.__index._jspService(__index.java:7826) > >> In the above example the EqualTag is calling > PropertyUtils but this > >> happens with all Struts tags that need to read a bean's > >> property value. > >> > >> This behaviour can be easily reproduced by a calling the 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). > >> > >> Although the problem seems to have been caused by Commons > Beanutils I > >> write to this mail group as this problem is new to Struts > >> 1.2.7 - and we > >> were not able to reproduce the problem with Struts 1.1: In > >> 1.1 the test > >> jsp's performance did not degrade by using more > concurrent threads but > >> keeps stable - and no locks were visisble in the thread > >> dumps. That's no > >> surprise because the classes PropertyUtilsBean and > BeanUtilsBean were > >> not uses in Struts 1.1 / the old Commons Beanutils version. > >> > >> > >> Does anyone else have this problem? Is there a workaround > or bugfix > >> available? > >> > >> Thanks in advance. > >> Jesper Richter-Reichhelm > >> > >> > >> > >> PS: > >> > >> The test JSP: > >> <!-- 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:iterat > >> e></logic: > >> iterate></logic:iterate></logic:notEmpty> > >> Finished! > >> <!-- end of test JSP --> > >> > >> > >> A test run with Struts 1.1: > >> siege -c10 -r20 "localhost:1701/dcw/test.jsp" > >> => There are no locks in the the thread dumps visible. > >> > >> > >> A test run with Struts 1.2.7: > >> 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(BeanUti > >> lsBean.jav > >> a:78) > >> - waiting to lock <0x6c86eab0> (a java.lang.Class) > >> at > >> org.apache.commons.beanutils.PropertyUtilsBean.getInstance(Pro > >> pertyUtils > >> Bean.java:101) > >> at > >> org.apache.commons.beanutils.PropertyUtils.getProperty(Propert > >> yUtils.jav > >> a: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) > >> ... > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]