We've seen similar issues with the moduleConfig variable. Have any of the committers looked at this one seriously? We use Struts in a clustered production environment, so a jump from 2M to 77M (in Maya's tests) presents a real issue.
From the way the problem's been described, it looks as if session synchronization could easily cause each individual session object to deserialize its own copy of the Struts config object tree. That would result in LOTS of identical copies. While the sessions originally created in the same VM would share a reference to one copy, each session pushed from one box to another in the cluster would serialize the struts config, send it over the network to the other servers, and then the receiving servers would deserialize that copy and create a whole new object tree (no longer sharing the reference to any existing Struts config stuff, even though it's identical).
This seems like a waste of memory and network bandwidth once Struts is used in a clustered environment. Many big sites are going to want to take advantage of clustering, so I assume this is an issue for others.
I didn't see a bug entered on Bugzilla. Is it more likely to receive committer discussion/attention if it were listed there? I know Joshua Bloch has a great section on custom de/serialization for the Singleton pattern (?) in his book "Effective Java", if that helps. I hope this issue can be resolved in some way to reduce the memory and network bandwidth needed in a clustered situation.
Thanks,
Tim
Maya Retzlaff wrote:
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]
