It's ok, theres no need to keep or persist images on reloads/restart/reboots.
Since images are graphs generates with jfreechart on measurements done live by the same webapp. So, upon reboot if the getattribute from servletcontext requesting an image returns null, i return a message from the servlet 'building image' Since the same call forces an image rebuild and the request is from ajax with a setinterval, on next request will be an image available. Worst scenario is no image for 5 seconds and thats acceptable for the webapp. Enviado desde blackberry -----Original Message----- From: Mark Thomas <ma...@apache.org> Date: Fri, 06 May 2011 09:09:55 To: Tomcat Users List<users@tomcat.apache.org> Reply-To: "Tomcat Users List" <users@tomcat.apache.org> Subject: Re: storing images On 06/05/2011 01:19, alexis wrote: > What i did (im testing and profiling it) is. > > As the images are around 10/12 and each image has around 30 to 35k. > > Im storing the images as servletcontext attribute. > > So calling to the servlet with ?code=1 builds and stores image1 on servlet > context. And returns html with <img src=servlet?get=1> > > So ajax sends that to the jsp that calls servlet?get and that returns the > image. > > It's working now, what im profiling is to verify no matter how many users are > requesting images, image1 is the same for every user and if one user builds > up the image again, all others gets the new one. > > As those images are stored on servletcontext, all are shared among the webapp > so images are not duplicated or triplicated or n-cated. > > I dont know if it's a good solution, but up to know it's working and really > fast. In short you are trading memory for speed. If you have the memory and need/want the speed then that is a good approach. A couple of things to think about: - What happens when the app is reloaded? Do you want to cache the generated images? - Do you want to pre-generate these images on application start? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org