流内容到JSF UI

Question

I was quite happy with my JSF app which read the contents of MQ messages received and supplied them to the UI like this:

<rich:panel>
<snip>
  <rich:panelMenuItem label="mylabel"  action="#{MyBacking.updateCurrent}">
    <f:param name="current" value="mylog.log" />    
  </rich:panelMenuItem>
</snip>
</rich:panel>

<rich:panel>
  <a4j:outputPanel ajaxRendered="true">
    <rich:insert content="#{MyBacking.log}" highlight="groovy" />
  </a4j:outputPanel>
</rich:panel>

and in MyBacking.java

private String logFile = null;
...

    public String updateCurrent() {
        FacesContext context=FacesContext.getCurrentInstance();
        setCurrent((String)context.getExternalContext().getRequestParameterMap().get("current"));
        setLog(getCurrent());
        return null;
    }

    public void setLog(String log) {
        sendMsg(log);
        msgBody = receiveMsg(moreargs);
        logFile = msgBody;
    }

    public String getLog() {
        return logFile;
    }

until the contents of one of the messages was too big and tomcat fell over. Obviously, I thought, I need to change the way it works so that I return some form of stream so that no one object grows so big that the container dies and the content returned by successive messages is streamed to the UI as it comes in.

Am I right in thinking that I can replace the work I'm doing now on a String object with a BufferedOutputStream object ie no change to the JSF code and something like this changing at the back end:

private BufferedOutputStream logFile = null;

    public void setLog(String log) {
        sendMsg(args);
        logFile = (BufferedOutputStream) receiveMsg(moreargs); 
    }

    public String getLog() {
        return logFile;
    }

Answer 1

If Tomcat fell over that, it must be over 128MB large or maybe double (which is the minimum default memory size of certain Tomcat versions). I don't think that users would value to visit a webpage which is that big. It may feel fast when acting as both server and client at localhost, but it will be up to 100 times slower when served over internets.

Introduce paging/filtering. Query and show just 100 entries at once or so. Add a filter which returns specific results, such as logs of a certain time range or of certain user, etc.

Google also doesn't show all the zillion available results at once in a single webpage, their servers would certainly "fell over" as well :)

Update as per the comment: Is the bean been put in the session scope or so? This way it will indeed accumulate in the memory soon. Streaming is only possible if you have an InputStream at the one side and an OutputStream at the other side. There is no way to convert a String to a stream that way as your casting attempt so that it won't be stored in the Java memroy anymore. The source has to stay at the other side and it has to be retrieved byte by byte over the line. The only feasible approach would be to use an <iframe> whose src points to some HttpServlet which directly streams the data from the source to the response.

Your best bet is likely to store the whole thing in a database or --if it doesn't contain user specific data-- in the application scope and share it among all sessions/requests.