Hi,
 
Thank for the quick response. I do retrieve and cache the report in chunks 
before i put it into the request scope as string. But i do not have control 
over the amount of data that i would retrieve from the host for the report. If 
may be few bytes or may be 1GB, how do you think that i a StringBuilder or a 
StringBuffer would help me when it comes to JSP. If possible can you put down a 
small example.
 
This is how my app looks like now.
 
HOST --> EJB (here i construct a DTO with a String variable called finalReport) 
    finalString is a String thats been toStringed from a StringBuffer.
 
Action Class:
    request.setAttribute("printview", responseDto);
 
JSP (get the finalString from the request object and use bean:write to write on 
the page)
   <logic:present name="printview">
       <FONT face="Courier New, Courier, mono"><pre><bean:write 
name="printview" property="finalReport" /></pre></FONT>
   </logic:present>
 
I hope this is clear and could you please suggest me a good approach to handle 
any size data.
 
Thank you.
 
Regards,
Sharon Jolly 
________________________________

From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Sent: Wed 1/3/2007 12:34 AM
To: Struts Users Mailing List
Subject: Re: Max length of String - report in a single string for display



What about retrieving and storing byte chunks? This way you don't have
to copy the data and its easier to write out the chunks one-by-one for
the outputstream too, since writing out a huge string is kindof messy
for the performance.
However it doesn't matter for the vm whether you store the data in
bytes or in strings, as long as the amount is the same, if you have no
heap you are screwed either way.

Of course you could pull the legacy system and write out the data
chunks immediately, this would remove the duty of caching them before
writing out and reduce memory overhead, but it would be hard to do so
if you get the data in the ejb layer (Or say less trivial).

One more sidenote: if you can ensure thread-safeness you should use
the StringBuilder instead of StringBuffer (jdk1.5 and above) since its
faster.

regards
Leon

On 1/2/07, Sharon Jolly <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am currently working on a struts based web application which interacts with 
> legacy systems to retrieve data for display and update. There is one scenario 
> in my application where the ejb layer makes multiple host calls to the legacy 
> system to retrieve data for a report. I was handling this by constructing a 
> string buffer each time the host retrieves 1821 bytes of data and when i get 
> an end of file flag from the host, i do a toString to the string buffer and 
> set it to the request scope in my Action class for dispaly in the report jsp.
>
> Problem Definition:
> The above scenario works fine as long as the size of the string in managable. 
> Now I want to increase the size of the report in the host to really large 
> one. Say previously i was displaying 1000 lines in the report using String, 
> now i want to increase it to 1,00,000 lines in the report. As far as i know 
> the String concept that i used previously will not work fine here, as max 
> length of the String is based on the heap size in JVM. (Am not sure as to 
> what's the max size of a string)
>
> I would really apperciate if someone could suggest me a good approach for 
> this problem so that i can come up with a design that would allow me to 
> display the entire report to the user irrespective of the size of the report, 
> that i retrieve from the host. (Any number of lines)
>
> Thank you and happy new year to one and all.
>
> Regards,
> Sharon Jolly
>
> ----------------------------------------------------------------DISCLAIMER---------------------------------------------------------
> Information transmitted by this EMAIL is proprietary to iGATE Group of 
> Companies and is intended for use only by the individual
> or entity to whom it is addressed and may contain information that is 
> privileged, confidential, or exempt from disclosure under
> applicable law. If you are not the intended recipient of this EMAIL 
> immediately notify the sender at iGATE or [EMAIL PROTECTED]
> and delete this EMAIL including any attachments
>
>


----------------------------------------------------------------DISCLAIMER---------------------------------------------------------
Information transmitted by this EMAIL is proprietary to iGATE Group of 
Companies and is intended for use only by the individual 
or entity to whom it is addressed and may contain information that is 
privileged, confidential, or exempt from disclosure under 
applicable law. If you are not the intended recipient of this EMAIL immediately 
notify the sender at iGATE or [EMAIL PROTECTED] 
and delete this EMAIL including any attachments

Reply via email to