depends on available bandwidth as well as the memory available on the clien=
t side
if bandwidth is an issue you may want to implement some manner of compressi=
on with jai (Java Advanced Imaging)
http://download.oracle.com/docs/cd/E17802_01/products/products/java-media/j=
ai/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 impl=
ement compression algorithm with another tool.
Martin=20
______________________________________________=20
Verzicht und Vertraulichkeitanmerkung/Note de d=E9ni et de confidentialit=
=E9
=20
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaeng=
er sein=2C so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiter=
leitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient l=
ediglich dem Austausch von Informationen und entfaltet keine rechtliche Bin=
dungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen w=
ir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut =EAtre privil=E9gi=E9. Si vous n'=EAtes=
pas le destinataire pr=E9vu=2C nous te demandons avec bont=E9 que pour sat=
isfaire informez l'exp=E9diteur. N'importe quelle diffusion non autoris=E9e=
ou la copie de ceci est interdite. Ce message sert =E0 l'information seule=
ment et n'aura pas n'importe quel effet l=E9galement obligatoire. =C9tant d=
onn=E9 que les email peuvent facilement =EAtre sujets =E0 la manipulation=
=2C nous ne pouvons accepter aucune responsabilit=E9 pour le contenu fourni=
.
> Subject: Re: storing images
> To: users@tomcat.apache.org
> From: alzrck@gmail.com
> Date: Fri=2C 6 May 2011 14:52:50 +0000
>=20
> I understand=2C but i have top 12 images of 35kbytes=2C no more.
>=20
> Encoding load is an issue yes=2C but the images are reflecting callcenter=
s 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 st=
art a different thread with a listener in charge to periodically rebuild im=
ages.
>=20
> Do you believe regarding memory it can cause a big issue? In worst case i=
t's 450kbytes when all images are created and stored.
>=20
>=20
> Enviado desde blackberry
>=20
> -----Original Message-----
> From: Christopher Schultz <chris@christopherschultz.net>
> Date: Fri=2C 06 May 2011 09:48:45=20
> To: Tomcat Users List<users@tomcat.apache.org>
> Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
> Subject: Re: storing images
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Alexis=2C
>=20
> On 5/5/2011 8:19 PM=2C alexis wrote:
> > Im storing the images as servletcontext attribute.
>=20
> Uh... in memory? That's a bad idea IMO for two reasons:
>=20
> 1. Large memory requirements
>=20
> 2. Likely repeated encoding into a file format like JPEG=2C PNG=2C etc.
>=20
> If you store the files on the disk=2C you can stream them as often as
> you'd like. If you get a request for an image that already exists=2C you
> can serve it up=2C otherwise=2C you can create it.
>=20
> 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.
>=20
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAk3D/D0ACgkQ9CaO5/Lv0PAYQQCcCy9k9SxH3YSHxekqSzJQKwPz
> nPAAn3XrYoxXE3E3+FXZ1XfBu3/v9pmW
> =3DrQaQ
> -----END PGP SIGNATURE-----
>=20
> ---------------------------------------------------------------------
> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands=2C e-mail: users-help@tomcat.apache.org
>=20
=
|