Thank you for the follow-up Spike!! I appreciate the specifics.
Spike wrote:
Hmmm...
This is very suspicious.
I don't think the friendlyURLData class is likely to be the cause of the problem because it's just using an instance of java.util.Properties to store the mappings internally. That's pretty much like a struct that only accepts a string as key and value, so the amount of memory used up by that should be pretty close to the size of the text file. It doesn't really do anything other than load them and return them when requested, so there shouldn't be any significant memory usage elsewhere in the class either.
I'm guessing that the problem is something to do with what's going on in fu.cfc. Probably the createAll() method.
I'll have a play when I get time and see exactly what's going on.
Spike
Michael @ Four Eyes wrote:
Just saw this post.
I have one client on a dedicated box in dev. The site has over 3200 nodes in the home tree. Basically the FU would not build. The first remedy was to raise the Maximum JVM Heap to 512, then to 1024. On another box we have about 8 clients live. Same deal. On our internal dev that we do most of our dev for the most past we keep FU off because we get a ton of lag, FU's mis-build or do not build, and general performance issues.
Now, don't get me wrong the FU is great and I love to use it. We have gotten used to some of it intricacies and recognize the steps we need to take to work with it. I do not think it is the FU alone, but perhaps combined with all the other structs loaded into memory it just happens to be an issue in some cases. Again, these are just the observations of me and my clients.
I like Chris's approach it reminds me of the the fusebox formUrl2Attributes SES hack -- except his is cleaner and is more light weight. In shared environments were the host does not want to load up servlets and config the web.xml, I think this is great approach.
Spike said "Putting it (fu.txt) in the application working directory might tempt people to try to operate on the text file directly which could have unforseen consequences." I, for one, think it would be better to have it in the app dir. For many of us we will either know exactly what we are looking at and know what not do. For others, well I have always believed that freedom needs to be tempered with self restraint.
Spike wrote:
The main reason for not doing that is because you'd have to somehow tell the servlet where that location was.
Since the text file is not supposed to be touched by anything except the servlet I think it's probably best to keep it where it is.
Just in case this isn't already known...
The sequence of operations is this:
The FriendlyURLData class gets loaded by fu.cfc.
When it gets loaded, it reads the text file and stores it in memory. From then on it always assumes that it has the latest copy and just overwrites the text file any time a mapping is added or modified.
Putting it in the application working directory might tempt people to try to operate on the text file directly which could have unforseen consequences.
Spike
Just a thought....Part of me wonders if it would make more sense to store the .txt file in the application working directory instead of in with the Java classes?
~tom
--- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
