A legtöbb XML lib a text node-okat be kell töltse egyben memóriába. Nyilván nem ismerem mindet, de amit ismerek az ilyen. Tehát a BASE64 string egyben a memóriában lesz, ami már eleve bukó. Hogy hogyan lesz ebből ennek a többszöröse, azt nem tudom a kód elemzése nélkül, de gondolom az XML lib a belsejében eszképel meg ilyenek, és persze ezt is objektumokba csinálja stream helyett.
Ahogy én csinálnám:
Generálnék XML-t memóriába úgy, hogy a bazi nagy Base64 helyett placeholder lenne ott. Például: <izé bizé="PLACEHOLDER_BASE64"/>
Kvázi pszeudókóddal:
Writer wr=response.getWriter();
wr.write(xmlPrefix);
Base64ToWriter(inputStream, wr);
wr.write(xmlPostfix);
Hasonló elv működhet akkor is ha több placeholder van, csak akkor kicsit bonyolultabb.
Szerk.: a parser oldalon még nagyobb lesz a baj, mert olyan API-t sem ismerek, ami nem töltené be egybe a szöveges entitásokat. (Egyébként ez béna, egy teljesítménykritikus alkalmazásban már okozott ez problémát a praxisomban. Úgy kellene működnie az XML parsernek, hogy van egy ) Tehát benn lesz a base64 változat RAM-ban.
Ha így kerülne be az XML-be a fájl:
<fájl>
<darab>base64darab</darab>
<darab>base64darab</darab>
....
<darab>base64darab</darab>
</fájl>
Akkor SAX api-val kicsi RAM-ban meg lehetne oldani. Még ekkor is fennáll a probléma, hogy a GC-t megpörgeti, mert a string ojjektumok létrejönnek, csak legalább nem egyszerre. Így simán belefér az egész néhány mega RAM-ba és a darabok méretével skálázódik.