RE: WAR file deployment snag - any suggestions?
Thanks very much for this. There are some very good points in here that have got me thinking. At present I have only one Tomcat running and a small number of users (it's an intranet) but the complexity and resource requirements of the application set is growing. I don't have any experience of larger scale web systems so all suggestions are welcome. Saving the XML files was an initial step at caching things that I can control. I did play around with holding onto the (dom4j) Documents in the ServletContext but I was concerned that this would swallow all the memory unless I used some sort of soft-reference caching system. I posted a question about this to this list - but I never heard back - must have been too dull a question (or the wrong list)! I imagine spreading the apps over multiple Tomcats/machines would allow me to do more in-memory caching. Feels like this is a move toward Web Services - I don't know much about them. Thanks again for your response - I'd be interested in hearing any other pearls of wisdom. Chris On Wed, Sep 29, 2004 at 06:27:13PM +0100, Chris Ward wrote: : Only having to release one file is great, but I've hit a problem : of my own making. My webapp writes various XML files to datestamped : dir within the webapp context. When I deploy the WAR file I purge : all these generated files. : [snip] : Should I use a different context to hold my data? That's one option; but another (likely more scalable) idea would be to put files in a filesystem, where they belong. The idea is to setup a directory outside of the Tomcat context path -- specify it in a properties file, or in a context param, whatever -- and write the data there. As the system grows to support multiple Tomcat instances spread across different machines, you could share the filesystem via NFS (not pretty, but it works), stuff the docs in a database (not pretty, but it works), or have the mid-tier Tomcat instances push the data to another, internal Tomcat setup that writes the files to a clustered/RAID'd fs. etc, etc, depending on how valuable these docs are and how much this app grows. By not writing to your context, you can wrap everything up in a WAR file and, better still, gain (a little) more security by making the WAR file owned and served by two different user accounts. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WAR file deployment snag - any suggestions?
On Thu, Sep 30, 2004 at 09:22:42AM +0100, Chris Ward wrote: : I imagine spreading the apps over multiple Tomcats/machines would allow : me : to do more in-memory caching. Feels like this is a move toward Web : Services : - I don't know much about them. This seems to have grown into a general app design question, of which I'm little help since I'm not working on your team. ;) All I can say, then, is to take a high-level look at what's supposed to happen and go from there. Ask yourself, what's to be achieved from storing this XML? Is it acceptable to lose it on system restart/crash or is it part of some corporate doc-retention policy? What are your tradeoffs between CPU (parsing XML from disk), RAM (storing in memory), and network (pushing data between hosts)? If you design this with flexibility in mind, you can easily move between in-memory, on-disk, and fetched-from-elsewhere storage (aka web services or another webapp). -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WAR file deployment snag - any suggestions?
Hi, I've just started to use ANT to build my webapp and then deploy it to Tomcat as a WAR file (using the catalina-ant.jar stuff). Only having to release one file is great, but I've hit a problem of my own making. My webapp writes various XML files to datestamped dir within the webapp context. When I deploy the WAR file I purge all these generated files. Anyone out there have any suggestions? Should I use a different context to hold my data? Would it be better to be running Apache as well as Tomcat? Best regards Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WAR file deployment snag - any suggestions?
On Wed, Sep 29, 2004 at 06:27:13PM +0100, Chris Ward wrote: : Only having to release one file is great, but I've hit a problem : of my own making. My webapp writes various XML files to datestamped : dir within the webapp context. When I deploy the WAR file I purge : all these generated files. : [snip] : Should I use a different context to hold my data? That's one option; but another (likely more scalable) idea would be to put files in a filesystem, where they belong. The idea is to setup a directory outside of the Tomcat context path -- specify it in a properties file, or in a context param, whatever -- and write the data there. As the system grows to support multiple Tomcat instances spread across different machines, you could share the filesystem via NFS (not pretty, but it works), stuff the docs in a database (not pretty, but it works), or have the mid-tier Tomcat instances push the data to another, internal Tomcat setup that writes the files to a clustered/RAID'd fs. etc, etc, depending on how valuable these docs are and how much this app grows. By not writing to your context, you can wrap everything up in a WAR file and, better still, gain (a little) more security by making the WAR file owned and served by two different user accounts. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
