Hi Dick
> I just looked briefly at the source. It says you are the
> author, so maybe
> you should know best? :-)
the author? no - just the author of the modifications about the
sorting! the glory about this piece of sw belongs to
Walter Szewelanczyk ;-))
Here some good news. Yesterday I could locate the problem!
It has to do how ComponentTag's doEndTag is processed by the table
tag. I added a fix which prevent this memory growing problem.
I've added my comments inline please have a look and tell
me if the fix makes sense or if we should make the modfications
somewhere else. Please try to tell me this asap because this
fix has to go in production.
original code snipplet (ComponentTag - doEndTag):
// Put params on the stack
addParameterInternal("label", findValue(labelAttr));
Object value = findValue(nameAttr);
if (value != null) {
addParameterInternal("name", value);
}
// If value attribute is not given, use the name
if (valueAttr == null) {
//>>> here the is the memory growing causing problem
//>>> on each same request when using the table
//>>> this method is called but it shoudn't
addParameterInternal("nameValue",
findValue(BeanUtil.toStringValue(value)));
} else {
if (log.isDebugEnabled()) {
log.debug("valueAttr:" + valueAttr);
log.debug("Setting value to:" + findValue(valueAttr));
}
addParameterInternal("nameValue", findValue(valueAttr));
}
this fixes the problem:
// Put params on the stack
addParameterInternal("label", findValue(labelAttr));
Object value = null;
//>>> look for the nameAttr only if we have one
if ( nameAttr != null )
{
value = findValue(nameAttr);
if (value != null) {
addParameterInternal("name", value);
}
}
// If value attribute is not given, use the name
//>>> call addParametrInternal if it makes sense
if (valueAttr == null) {
if ( value != null ){
addParameterInternal("nameValue",
findValue(BeanUtil.toStringValue(value)));
}
} else {
if (log.isDebugEnabled()) {
log.debug("valueAttr:" + valueAttr);
log.debug("Setting value to:" + findValue(valueAttr));
}
addParameterInternal("nameValue", findValue(valueAttr));
}
Cheers
-Paolo
>
> Cheers,
>
> Dick Zetterberg
>
> ----- Original Message -----
> From: "Vedovato Paolo" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, February 05, 2004 5:05 PM
> Subject: RE: [OS-webwork] WW1.3 Memory Consumption
>
>
> > Ok, I Found some more on this issue.
> >
> > This Query problems occur only when the <ww:table> tag is used.
> >
> > As far as i see in my Profiling Tool the WebTable component
> > tries to do something 'illegal' in the doEndTag.
> >
> > It always tries to find something in this form
> >
> > [EMAIL PROTECTED]
> >
> > and of course this reference changes on each request putting
> > it in the Query Hashtable and so this grows with each
> > request.
> >
> > Any clues about this phenomena?
> >
> > Cheers
> > -Paolo
> >
> >
> > > -----Original Message-----
> > > From: Vedovato Paolo
> > > Sent: Thursday, February 05, 2004 9:53 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: [OS-webwork] WW1.3 Memory Consumption
> > >
> > >
> > > Hi Dick
> > >
> > > for my replies see inline.
> > >
> > > > You are right that the Query class contains a cache of all
> > > expressions
> > > > (instances of Query). It is a static HashMap in WW1.3 so it
> > > > is never GC'd as
> > > > you know.
> > > > I can see a couple of cases that would make it grow:
> > > >
> > > > 1. Parameters that are sent in requests are set on actions
> > > > with the help of
> > > > the Query class. If you always have new parameter names, then
> > > > they will
> > > > generate new Query objects that will fill up the cache. So
> > > > for example the
> > > > parameters:
> > > > myaction.action?paramOne=2&otherParam/subProperty=4 this
> > > > would create 2 new Query instances (and 3 QuerySegments
> I believe).
> > > > Do you have some parameters that have dynamic names?
> > > Do you mean the first request calls 'paramOne=2', after
> > > that the same request calls 'paramTwo=2'?
> > > No, we don't have dynamic names parameters...
> > >
> > > > 2. Some usages of the expand functionality of the expression
> > > > language (when
> > > > you use braces { } ) can give many Query objects. For example
> > > > if you write:
> > > > <ww:property value="{myProp}"/> then myProp is looked up,
> > > and whatever
> > > > String myProp contains is then looked up. This means that if
> > > > myProp contains
> > > > different String values all the time then alot of Query
> > > > instances will be
> > > > created.
> > > The only constructs I find in our application which could match
> > > are the following:
> > >
> > > - the templates checkbox.jsp, password.jsp, text.jsp etc.
> > > - <ww:text name="'{0,date,EEEE, dd.MM.yyyy, HH:mm}'"
> value0="@today"/>
> > > - <ww:text name="'{0,number,#,##0.00}'"
> value0="@dep/balance/amount"/>
> > >
> > > Do you see problems with it?
> > >
> > > > You can also try changing the Map to be a WeakHashMap and
> > > > then the Query
> > > > instances could be GC'd. But of course it would be better to
> > > > find the real
> > > > cause of the problem first.
> > > That would be a possibility but as you said we should try
> to find the
> > > real cause.
> > >
> > > Anyway I would like to thank you for the help!
> > >
> > > Cheers
> > > -Paolo
> > >
> > >
> > > -------------------------------------------------------
> > > The SF.Net email is sponsored by EclipseCon 2004
> > > Premiere Conference on Open Tools Development and Integration
> > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > > http://www.eclipsecon.org/osdn
> > > _______________________________________________
> > > Opensymphony-webwork mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
