Dear Developers, 

I've been lurking on the developers list for a while and submitted the
questions/problems below to the struts-user list. Unfortunately I haven't
gotten a reply, and I was recommended to try the developers list. I hope,
that posting this list to the developer list, is not to big a breech of
protocol. 

Best regards

/Maya Retzlaff

ps. Due to time differences I might be a bit slow in replying ds.

> -----Original Message-----
> From: Maya Retzlaff [mailto:[EMAIL PROTECTED]
> Sent: den 28 juli 2003 21:19
> To: 'Struts Users Mailing List'
> Subject: RE: Memory consumption 1.1 b3 vs. 1.1 final
> 
> 
> Hi, 
> 
> Unfortunate no one replied. But I'll try again with more information.
> 
> After a bit more debugging, when using the debugger see screen shot. 
> http://maya.retzlaff.se/debugScreenShot.png, sorry couldn't 
> export to text.
> Its a bit censored.
> 
> This means that the whole struts-config.xml (a HashMap with 
> 127 elements) is
> saved in the session for every user when <action 
> scope="session"> is set in
> struts-config.xml. For us with the memory restrictions we 
> face, the 50k that
> the strutsconfig takes in memory is very severe. 
> If this is a conscious design description, it would be very 
> good to hear the
> reasons. 
> If not could we in anyway work with someone to help debug it 
> so we could
> submit a patch?
> 
> Now when comparing the source files for the different 
> releases we can't find
> anything significantly different in any of these classes. And 
> finding where
> moduleconfig gets set into the FormBeanConfig is untraceable. 
> Is it done in
> apache.commons? 
> 
> A search in bugzilla either hasn't yielded anything either, 
> regrettably
> 
> We are on a schedule and need to have this solved on Weds, 
> otherwise we need
> to go back to the 1.1 b3 release. Obviously we would prefer to use the
> stable 1.1 release.
> 
> Help would be very much appreciated. 
> 
> 
> /Maya
> 
> > -----Original Message-----
> > From: Maya Retzlaff [mailto:[EMAIL PROTECTED]
> > Sent: den 25 juli 2003 19:57
> > To: 'Struts Users Mailing List'
> > Subject: Memory consumption 1.1 b3 vs. 1.1 final
> > 
> > 
> > Hi, 
> > 
> > Me and my colleagues are developing a web application in an 
> > environment of
> > very strict memory limitations, for instance the session size 
> > per user is
> > limited to 15k. 
> > If we go over the limit the application fails. Its out of 
> our control
> > unfortunately. 
> > 
> > We are subclassing the DynaActionForm for use in our own 
> > forms, when this
> > form is saved to the session, which we do in rare cases, it 
> > uses quite a lot
> > of memory. 
> > 
> > We were previously running on jakarta-struts-1.1-b3 from 
> > October release
> > which caused no problem. Below is a comparison of the memory 
> > consumption
> > with 1.1 Final on the _same_ form 
> > 
> > Running on the same version of tomcat:
> > 
> > 1.1 b3  2344 k
> > 1.1 Final 76624 k
> > 
> > When debugging (serializing and back) we found that the 
> > DynaAction uses
> > FormBeanConfig which in turns refer to ModuleConfigImp which keeps a
> > reference to the complete struts config file. This in our 
> > case, where we
> > don't use modules but have all the config info in one class, 
> > takes quite a
> > lot of memory. 
> > 
> > In comparing directories, and source from the two different 
> > releases nothing
> > obvious appears. 
> > 
> > The memory problem still appears on our wml interface site where we
> > ourselves implemented the "front end" bits of struts instead 
> > of struts-html,
> > we can rule out a fair chunk of the struts classes. 
> > 
> > Has anyone else come across the problem? Any suggestions on 
> > how we could
> > reduce the size. 
> > 
> > We'd be very grateful for help as the release date for the 
> > project we are
> > working is starting to get uncomfortably close. 
> > 
> > Best Regards
> > /Maya
> > 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to