懒的态度

一转眼已经到了十月，我的草稿箱里还存着一个八月遇到的诡异bug：在我们的Spring Boot应用程序里，用到了Spring Security和Spring Session，这两个modules一直以来相安无事，直到有一天…… 使用Hibernate的时候如果查询结果集合过大，会导致response无法迅速返回。这里有两个要命的问题，首先由于Query在执行的时候JDBC的block调用过长，HTTP Gateway会超时；其次结果集过大意味着Hibernate在真正写入response （例如将结果集转换为DTO再写入CSV）之前不得不在内存中持有所有结果的对象引用，最终会致内存占用的问题，要么GC要么OutOfMemory。 为了解决在查询结果下载时遇到的问题，我们用到了`StatelessSession`和`ScrollableResult`来获取一个相当大的`ResultSet`，通过Java 8 的`Stream` 来访问单个元素，从而实现stream downloading。但是在调试中发现无法得到完整的CSV结果，经常是写到半当中就EOF了？！ 同事老R花了大半天的时间来debug，最终无比惊讶的发现是Spring在控制`HttpServletResponse`的committed事件时有隐藏手段——`OnCommittedResponseWrapper`。貌似这个class在 [Spring Session](https://github.com/spring-projects/spring-session/blob/master/spring-session-core/src/main/java/org/springframework/session/web/http/OnCommittedResponseWrapper.java) 和 [Spring Security](https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/util/OnCommittedResponseWrapper.java) 内各自有一份copy，而且还并非完全一样。 /** * Imp...

HTTP无疑是日常生活中使用最多的Internet协议之一。在企业级别的应用程序中，HTTP是当之无愧的最受程序员喜爱的通信协议。最近恰好在做几个简单的HTTP程序，为了更好的看清常见的GET/POST等指令是如何应用于实际通讯中的，截取了一段interaction log。 第一部分是HTTP Request，这里show的是GET method。 GET /polish/j2mepolish-2.0-beta3.jar HTTP/1.1 Host: download.berlios.de Accept: */* Referer: http://prdownload.berlios.de/polish/j2mepolish-2.0-beta3.jar User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98) Pragma: no-cache Cache-Control: no-cache Connection: close 第二部分是server的response。 HTTP/1.1 200 OK Date: Sat, 13 Jan 2007 06:57:28 GMT Server: Apache/2.0.54 (Linux/SUSE) X-Powered-By: PHP/4.4.0 Cache-Control: must-revalidate, post-check=0, pre-check=0 Content-Length: 21453320 Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="j2mepolish-2.0-beta3.jar"; Connection: close Content-Type: application/x-download