【问题标题】:BufferedReader inconsistently hanging on my socket's inputstreamBufferedReader 不一致地挂在我的套接字的输入流上
【发布时间】:2013-08-24 14:09:26
【问题描述】:

我正在编写一个 Java HTTP 服务器。我认为整个服务器都在工作并且它正在使用线程。但是,我意识到将请求读入 BufferedReader 的那段代码无法始终如一地工作。

这是读取传入请求的代码:

private String receive(WebSocket webSocket) throws IOException {
  int chr;
  System.out.println("Receiving!");
  StringBuffer buffer = new StringBuffer();

  while ( (chr = webSocket.in().read() ) != -1) {
    buffer.append((char) chr);
    if ( !webSocket.in().ready())
      break;
  }
  return buffer.toString();
}

我的 Websocket 类只是包装了 Socket 并提供了输入和输出。我这样做是为了模拟套接字并测试我的服务器。

Websocket 类如下所示:

package http.server.socket;

import java.io.*;
import java.net.Socket;

public class SystemSocket implements WebSocket {
  private Socket theConnection;
  private BufferedReader in;
  private OutputStream out;

  public SystemSocket(Socket theConnection) throws IOException {
    this.theConnection = theConnection;
    in = new BufferedReader(new InputStreamReader(theConnection.getInputStream()));
    out = new BufferedOutputStream(theConnection.getOutputStream());
  }

  public BufferedReader in() throws IOException {
    return in;
  }

  public OutputStream out() throws IOException {
    return out;
  }

  public void close() throws IOException {
    in.close();
    out.close();
    theConnection.close();
  }
}

问题在于,用户在浏览器中输入的每个 url 都会发出两个请求 - 一个用于请求的页面,一个用于 favicon。有时 - 似乎 - 网站图标请求没有进入并且线程挂起。

这是我打印到控制台的一些调试信息一切顺利时

Receiving!
Receiving!
REQUEST STRING = GET /color_picker.html HT
[20130821 20:29:23] REQUEST: http://localhost:5000/color_picker.html
[20130821 20:29:23] PAGE RENDERED
REQUEST STRING = GET /favicon.ico HTTP/1.1
[20130821 20:29:23] REQUEST: http://localhost:5000/favicon.ico
[20130821 20:29:23] PAGE RENDERED

每当读取请求时,都会打印“正在接收”消息。所以,在这种情况下,“接收”消息被打印了两次,两个请求进来了,两个东西被渲染了。但是,同一个页面(但在不同的时间)会这样做(大约 10 秒后)

Receiving!
Receiving!
REQUEST STRING = GET /color_picker.html HTTP/1.1
[20130821 20:41:25] REQUEST: http://localhost:5000/color_picker.html
[20130821 20:41:25] PAGE RENDERED
REQUEST STRING = 
Exception in thread "ServerThread" java.lang.ArrayIndexOutOfBoundsException: 1
  at http.request.Parser.setRequestLineData(Parser.java:42)
  at http.request.Parser.setRequestHash(Parser.java:27)
  at http.request.Parser.parse(Parser.java:13)
  at http.request.Request.get(Request.java:18)
  at http.server.ServerThread.run(ServerThread.java:39)

所有后续错误都是因为请求字符串为空。但我无法弄清楚为什么请求字符串为空。我什至无法弄清楚如何调试。

谁能帮忙??

另外需要注意的是,如果第二个请求字符串没有立即进入,用户可以请求一个新的 url,这将导致第二个挂起的过程完成(那么第四个请求的 url 将是什么挂起) .因此,只有当用户停止请求时,在大约 10 秒后的最后一次请求中,我才会收到错误消息。有时我可以请求 20 个不同的页面,只有在我停止请求页面并等待几秒钟后,我才会看到错误。我想这是怎么回事??

更新:

根据请求,这里是 setRequestLineData() 方法:

private void setRequestLineData() {
  requestHash = new HashMap<String, String>();

  if (requestLineParts.length == 3) {
    requestHash.put("httpMethod", requestLineParts[0]);
    requestHash.put("url", requestLineParts[1]);  //line 42
    requestHash.put("httpProtocol", requestLineParts[2]);
  }
  else {
    requestHash.put("httpMethod", requestLineParts[0]);
    requestHash.put("url", requestLineParts[1]);
    requestHash.put("queryString", requestLineParts[2]);
    requestHash.put("httpProtocol", requestLineParts[3]);
  }
}

更新:

在导师的帮助下,我想我对这里发生的事情有了更多了解。他的想法是,一旦收到一个请求,浏览器会立即启动另一个请求,以减少下一个请求的加载时间。这听起来对我来说是合理的,因为我可以一页又一页地加载页面,但是在请求最后一页之后大约 10 秒我得到了一个错误。目前,我正在使用自定义异常处理此问题,但正在研究更好的解决方案。感谢所有的帮助家伙!

【问题讨论】:

  • http.request.Parser 是你的班级吗?请告诉我们setRequestLineData() 方法。
  • 想提一下为什么投反对票?如果你让我知道,我仍然可以提供帮助。
  • 我没有对你投反对票@MarioRossi。对不起。
  • @GregKopff,我添加了它。它只是试图解析请求,当请求为空时,它会抛出错误。

标签: java http inputstream bufferedreader


【解决方案1】:

ready() 不是对消息结束的有效测试。它只告诉你是否有数据可以在没有阻塞的情况下读取。 TCP 不是面向消息的协议,它是一个字节流协议。如果你想要消息,你必须自己实现它们,例如作为行、长度-值元组、类型-长度-值元组、序列化对象、XML 文档……

ready()(或available())的正确用法很少(如果有的话),这不是其中之一。

【讨论】:

  • 谢谢你,EJP。根据 Java Docs,“底层流的 ready 方法返回 false,表示进一步的输入请求会阻塞。”似乎流是空的并且正在阻塞。因此,如果它确实阻塞,我正在使用该命令来中断。我还尝试在另一个 while 循环中围绕 while 循环检查 ready() 但它没有用。你还有什么建议吗?我在正确的轨道上吗?
  • 重点是阻塞与消息完成无关。您必须继续阅读,直到收到完整的消息,而 ready() 无法帮助您。如果获取竞争消息涉及阻止,那就这样吧。
猜你喜欢
  • 1970-01-01
  • 2011-08-24
  • 1970-01-01
  • 2016-07-28
  • 2012-09-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-21
相关资源
最近更新 更多