depends on available bandwidth as well as the memory available on the client side if bandwidth is an issue you may want to implement some manner of compression with jai (Java Advanced Imaging)
http://download.oracle.com/docs/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/com/sun/media/jai/codec/TIFFEncodeParam.html if your app is rendering small pics where clarity is not a requirement you probably will never have an issue if your app is rendering large maps then you'll need to look at JAI or implement compression algorithm with another tool. Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Subject: Re: storing images > To: users@tomcat.apache.org > From: alz...@gmail.com > Date: Fri, 6 May 2011 14:52:50 +0000 > > I understand, but i have top 12 images of 35kbytes, no more. > > Encoding load is an issue yes, but the images are reflecting callcenters call > queues and some stuff related so the need to refresh and rebuild the images > is a requirement. What im thinking is to avoid the generation upon servlet > calls (servlet only reads and presents the image to callers) and start a > different thread with a listener in charge to periodically rebuild images. > > Do you believe regarding memory it can cause a big issue? In worst case it's > 450kbytes when all images are created and stored. > > > Enviado desde blackberry > > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Date: Fri, 06 May 2011 09:48:45 > To: Tomcat Users List<users@tomcat.apache.org> > Reply-To: "Tomcat Users List" <users@tomcat.apache.org> > Subject: Re: storing images > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alexis, > > On 5/5/2011 8:19 PM, alexis wrote: > > Im storing the images as servletcontext attribute. > > Uh... in memory? That's a bad idea IMO for two reasons: > > 1. Large memory requirements > > 2. Likely repeated encoding into a file format like JPEG, PNG, etc. > > If you store the files on the disk, you can stream them as often as > you'd like. If you get a request for an image that already exists, you > can serve it up, otherwise, you can create it. > > You can even create a hash of lock objects or something so that you can > "lock" the file as it's being written so that the file is only written > once even if multiple clients are requesting it. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk3D/D0ACgkQ9CaO5/Lv0PAYQQCcCy9k9SxH3YSHxekqSzJQKwPz > nPAAn3XrYoxXE3E3+FXZ1XfBu3/v9pmW > =rQaQ > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
