Hi, Excuse the crossposting, the discussion have been on both lists, and parties on both lists have replied so here it goes.
We know the problem had to do with serializing, and deserializing. This is what happened: The source we downloaded (Friday) for struts-jakarta-b3 was modified later then the version we had been using. So we decompiled the old struts jar. And did a diff on that file with the new one. In the decompiled version of b3 of org.apache.struts.config.ActionFormConfig, the moduleConfig field didn't exist. Thus wasn't serialized when a formbean was put into the session scope. We have successfully tested a change to struts by making the moduleConfig field in org.apache.struts.config.ActionFormConfig transient. This solves our session size problems but makes deserialization of DynaActionForm instances uncertain. We don't see the reason why the moduleConfig should be serialized and deserialized. Could you confirm that this shouldn't cause any problems? We don't know if the forms will work after deserialization when the session gets swapped to another container. Do you agree? We have only tested on our own applications, but would of course be interested in having this fixed in a nightly release of struts. Best regards /Maya > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: den 29 juli 2003 13:41 > To: Struts Developers List > Cc: [EMAIL PROTECTED] > Subject: Re: FW: Memory consumption 1.1 b3 vs. 1.1 final > > > Except for some of the Sun libraries, there is absolutely no closed > source in the Struts distribution. So, everything should be > traceable if > you have all the Common source packages on board. In this > case, you may > need the Commons BeanUtils source. > > The <action scope="session" ... /> property is meant to refer to the > ActionForm for that mapping and should not affect any object > represented > in the struts-config. To have the ActionForms default to > request scope, > you can specify another classname in the action-mappings element. The > RequestActionMapping class is provided for that purpose. > > AFAIK, the only objects Struts would ever store in the session are a > session-scoped ActionForm, a Locale object, and a session-scoped > exception error. The other objects specified by the > struts-config should > be stored in application scope and shared by all clients. > > I believe what you are looking at is a pointer from the > DynaActionForm > to the shared configuration in application scope. If we are somehow > copying the Struts Configuration into the session scope, then, yes, I > believe that would be a bug ... or at least a feature that > needs to be > reconsidered =:0) > > -Ted. > > Maya Retzlaff wrote: > > 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] > > > > > > > -- > Ted Husted, > Junit in Action - <http://www.manning.com/massol/>, > Struts in Action - <http://husted.com/struts/book.html>, > JSP Site Design - > <http://www.amazon.com/exec/obidos/ISBN=1861005512>. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
