java - 将内容流式传输到 JSF UI

Question

我对我的 JSF 应用程序非常满意，它读取收到的 MQ 消息的内容并将它们提供给 UI，如下所示:

<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>

和 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;
    }

直到其中一条消息的内容太大，tomcat摔倒了。显然，我想，我需要改变它的工作方式，以便返回某种形式的流，这样就不会因为任何对象变得太大而导致容器死亡，并且连续消息返回的内容会在传入时流式传输到 UI。

我是否正确地认为我可以用 BufferedOutputStream 对象替换我现在在 String 对象上所做的工作，即无需更改 JSF 代码，并且在后端进行类似的更改:

private BufferedOutputStream logFile = null;

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

    public String getLog() {
        return logFile;
    }

Answer 1

如果 Tomcat 遇到了这个问题，它必须超过 128MB 或者可能是两倍(这是某些 Tomcat 版本的最小默认内存大小)。我认为用户不会愿意访问这么大的网页。在本地主机上充当服务器和客户端时可能感觉很快，但通过互联网提供服务时速度会慢 100 倍。

引入分页/过滤。一次仅查询并显示 100 个条目左右。添加返回特定结果的过滤器，例如某个时间范围或某个用户​​的日志等。

Google 也不会在一个网页中同时显示所有可用的结果，他们的服务器肯定也会“崩溃”:)

更新按照评论:bean 是否已放入 session 范围内？这样确实很快就会在内存中积累起来。仅当您拥有 InputStream 时才可以进行流式传输在一侧和 OutputStream在另一边。没有办法像你的转换尝试那样将字符串转换为流，这样它就不会再存储在 Java 内存中。源必须留在另一端，并且必须通过线路逐字节检索。唯一可行的方法是使用 <iframe>谁的src指向一些HttpServlet它直接将数据从源流式传输到响应。

您最好的选择可能是将整个内容存储在数据库中，或者(如果它不包含用户特定数据)存储在应用程序范围中，并在所有 session /请求之间共享它。