• Web ’ 目錄歸檔

    《Spring 5 官方文檔》22. WebSocket Support

    原文鏈接? 譯者信息:Dan ?QQ:903585177

    22. WebSocket 支持

    參考文檔的這一部分涵蓋了Spring框架對Web應用程序中WebSocket風格消息傳遞的支持,包括使用STOMP作為應用程序級WebSocket子協議。

    Section 22.1, “Introduction” 建立一個WebSocket的大致框架,涵蓋應用挑戰,設計考慮以及何時適合的想法。

    Section 22.2,“WebSocket API” 介紹了服務端的Spring WebSocket API,Section 22.3,“SockJS Fallback Options” 介紹了SockJS 協議,并且展示如何配置和使用它.

    Section 22.4.1, “Overview of STOMP” 介紹 STOMP 信息協議. Section 22.4.2, “Enable STOMP over WebSocket” 展示如何在Spring配置STOMP. Section 22.4.4, “Annotation Message Handling” 以下部分說明如何編寫注釋消息處理方法,發送消息,選擇消息代理選項,以及與特殊“用戶”目的地的工作. 最后, Section 22.4.18,“Testing Annotated Controller Methods” 列出了測試STOMP / WebSocket應用程序的三種方法.

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 《Spring 5 官方文檔》22. WebSocket Support


    《Http Client 官方文檔》7. 高級主題

    原文鏈接 譯者:flystarfly

    第七章 高級主題

    7.1. 自定義客戶端連接

    在某些情況下,有必要自定義HTTP消息傳輸的方式來擴展HTTP參數的可使用性,以便能夠處理非標準的作業。 例如,對于網絡爬蟲,可能需要強制HttpClient接受格式不正確的響應頭,來捕捉消息的內容。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 《Http Client 官方文檔》7. 高級主題


    《HttpClient 官方文檔》第三章 HTTP 狀態管理

    原文鏈接 譯者[陳志軍]

    通常 HTTP 被設計為無狀態,面向請求/響應的協議,對于有一些邏輯相關的請求/響應交換的有狀態會話沒有特別的規定。正當 HTTP 協議越來越流行和被認可,越來越多之前沒有打算使用它的系統,現在也開始為了應用程序而使用它。例如電子商務應用的內容傳輸。因此,支持 HTTP 狀態管理變得非常有必要。
    NetScape(網景公司),曾經引領網頁客戶端和服務器端軟件的發展,在他們的產品中基于專有的規范,提供了 HTTP 狀態管理的支持。之后,NetScape 嘗試通過發布規范草案來標準化這種機制。這些努力通過 RFC 標準促進了正式的規范定義。但是,狀態管理在很多應用程序中仍然支持 Netscape 的草案而不兼容官方的標準。很多Web瀏覽器的主要開發人員覺得有必要保留這些極大地促進標準兼容性的草案。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 《HttpClient 官方文檔》第三章 HTTP 狀態管理


    《HttpClient 官方文檔》第五章 Fluent API

    原文鏈接 ?譯者[white]

    第五章:流式 API

    5.1 易用 API 接口

    4.2版本的 HttpClient 帶來了一組非常容易使用的流式 API(Fluent API) 接口。暴露的流式API(Fluent API) 接口中僅僅是 HttpClient 最基本的一些功能,這些接口是在不需要使用 HttpClient 豐富的靈活性時,為了一些簡單的功能而準備的。 例如:流式接口(Fluent API) 增加了使用者對連接的管理和資源的分配上的便利性。這里有一系列通過 HttpClient 流式接口(Fluent API) 執行 HTTP 請求的示例:

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 《HttpClient 官方文檔》第五章 Fluent API


    《Apache Velocity用戶指南》官方文檔

    原文鏈接? ?譯文連接 譯者:小村長 ?校對:方騰飛

    Quick Start

    本項目是 Apache Velocity官方文檔的中文翻譯版,Velocity類似與JSP,是一種基于Java的模板引擎。它可以在web頁面中引用Java代碼中定義的數據和對象,而Velocity的作用就是把Web視圖和java代碼進行組裝在一起。本次翻譯主要針對對Velocity感興趣和工作中使用到Velocity的開發人員提供有價值的中文資料,希望能夠對大家的工作和學習有所幫助。

    由于我也是第一次接觸Velocity,還不是很深入,翻譯的時候也查看了一些博客以及其他網上資料。也嘗試著去了解它和JSP方面的差別以及優缺點,同時也去了解了下它和其他Java引擎模板的區別,比如freemaker的區別,等等。但是還是因為能力見識有限,翻譯過程中難免出現個人的主觀或者客觀原因導致與官方文檔存在差異。在此,我還是建議有能力的童鞋能夠自己去Velocity官方看看。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 《Apache Velocity用戶指南》官方文檔


    JSON數據亂碼問題

    背景
    程序員一提到編碼應該都不陌生,像gbk、utf-8、ascii等這些編碼更是經常在用,但時不時也會出個亂碼問題,解決這個問題的方法大部分都是先google和baidu一下,最后可能在某個犄角旮旯里找到一點信息,然后就機械的按部就班的模仿下來,結果問題可能真就迎刃而解了,然后就草草了事,下回遇到相似的問題,可能又是重復上面的過程。很少有人有耐心去花精力弄明白這寫問題的根本原因,以及解決這些問題的原理是什么。這篇文章就是通過一個實際案例,試著去講清楚什么是編碼,亂碼又是怎么產生的,以及如何解決。該案例是從lua_cjson.c這個庫開始的,對這個庫不熟悉也沒關系,也不需要熟悉它,我們只是借用它來說明亂碼問題,只需要跟著文章的思路走就可以。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: JSON數據亂碼問題


    《 Java并發編程從入門到精通》Thread安全與不安全

    javaC作者:張振華 ? ?購買鏈接:天貓商城? JD商城 ?當當書店

    鳥欲高飛先振翅,人求上進先讀書。本文是原書的第3章 ?Thread安全3.2 什么是不線程安全。3.3什么是線程不安全。

    3.2 什么是不安全?

    當多個線程同時操作一個數據結構的時候產生了相互修改和串行的情況,沒有保證數據的一致性,我們通常稱之這種設計的代碼為”線程不安全的“。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 《 Java并發編程從入門到精通》Thread安全與不安全


    Tomcat-connector的微調(3): processorCache與socket.processorCache

    tomcat在處理每個連接時,Acceptor角色負責將socket上下文封裝為一個任務SocketProcessor然后提交給線程池處理。在BIO和APR模式下,每次有新請求時,會創建一個新的SocketProcessor實例(在之前的tomcat對keep-alive的實現邏輯里也介紹過可以簡單的通過SocketProcessorSocketWrapper實例數對比socket的復用情況);而在NIO里,為了追求性能,對SocketProcessor也做了cache,用完后將對象狀態清空然后放入cache,下次有新的請求過來先從cache里獲取對象,獲取不到再創建一個新的。

    這個cache是一個ConcurrentLinkedQueue,默認最多可緩存500個對象(見SocketProperties)??梢酝ㄟ^socket.processorCache來設置這個緩存的大小,注意這個參數是NIO特有的。

    接下來在SocketProcessor執行過程中,真正的業務邏輯是通過一個org.apache.coyote.Processor的接口來封裝的,默認這個Processor的實現是org.apache.coyote.http11.Http11Processor。我們看一下SocketProcessor.process(...)方法的大致邏輯:

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Tomcat-connector的微調(3): processorCache與socket.processorCache


    Tomcat-connector的微調(2): maxConnections, maxThreads

    1) 最大連接數

    tomcat的最大連接數參數是maxConnections,這個值表示最多可以有多少個socket連接到tomcat上。BIO模式下默認最大連接數是它的最大線程數(缺省是200),NIO模式下默認是10000,APR模式則是8192(windows上則是低于或等于maxConnections的1024的倍數)。如果設置為-1則表示不限制。

    在tomcat里通過一個計數器來控制最大連接,比如在Endpoint的Acceptor里大致邏輯如下:

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Tomcat-connector的微調(2): maxConnections, maxThreads


    Tomcat-connector的微調(1): acceptCount參數

    對于acceptCount這個參數,含義跟字面意思并不是特別一致(個人感覺),容易跟maxConnections,maxThreads等參數混淆;實際上這個參數在tomcat里會被映射成backlog:

    static {
        replacements.put("acceptCount", "backlog");
        replacements.put("connectionLinger", "soLinger");
        replacements.put("connectionTimeout", "soTimeout");
        replacements.put("rootFile", "rootfile");
    }
    

    backlog表示積壓待處理的事物,是socket的參數,在bind的時候傳入的,比如在Endpoint里的bind方法里:

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Tomcat-connector的微調(1): acceptCount參數


    處理JSON的Java API :JSON的簡介

    原文鏈接??作者:Jitendra Kotamraju ? 譯者:撒木

    處理JSON的各種解析、生成、處理、轉換和查詢的JAVA API

    JSON?(JavaScript Object Notation)是一種輕量級的、基于文本的、完全獨立于語言的數據交換格式。它非常方便人們和機器的閱讀和書寫。JSON 有兩種結構類型的表現方式對象和數組。對象是名/值對的無序集合。數組是值(value)的有序集合。值的類型可以是字符串(在雙引號中)、數字(整數或浮點數)、邏輯值(true或false)、數組(在方括號中)、對象(在花括號中)、null。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: 處理JSON的Java API :JSON的簡介


    Netty-Mina深入學習與對比(二)

    感謝支付寶同事[易鴻偉]在本站發布此文。

    上文netty-mina深入學習與對比(一)講了對netty-mina的線程模型以及任務調度粒度的理解,這篇則主要是講nio編程中的注意事項,netty-mina的對這些注意事項的實現方式的差異,以及業務層會如何處理這些注意事項。

    1. 數據是如何write出去的

    java nio如果是non-blocking的話,在每次write(bytes[N])的時候,并不會將N字節全部write出去,每次write僅一部分(具體大小和tcp_write_buffer有關)。那么,mina和netty是怎么處理這種情況的呢?

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Netty-Mina深入學習與對比(二)


    Web Services 概述

    原文鏈接,譯文鏈接,譯者:朱張鎖,校對:郭蕾

    術語“web服務”經常用來描述一個客戶端(計算機)可通過互聯網進行遠程調用一個服務,通過諸如HTTP的Web協議。比如調用不同機器上的一個方法、過程或函數。因此Web服務非常類似于是“遠程過程調用”(或只是“遠程”)協議。比如java的RMI,Windows DCOM,CORBA的IIOP等。這些Web服務的原理如下圖所示:

    web-service-overview-1

    (一個客戶端通過互聯網調用Web服務)

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Web Services 概述


    Tomcat7.0.26的連接數控制bug的問題排查

    感謝同事[空蒙]的投稿。

    首先感謝@烈元一起排查此問題。今天發現線上一臺機器,監控一直在告警,一看是健康檢查不通過,就上去查看了下,首先自己curl了下應用的url,果然是超時沒有響應,那就開始按順序排查了:

    1、?load非常低,2、gc也正常,3、線程上也沒死鎖,4、日志一切正常。那是什么情況呢,不能忘記網絡啊。果然,netstat命令一把,結果如下:

    TIME_WAIT 68
    CLOSE_WAIT 194
    ESTABLISHED 3941
    SYN_RECV 100
    

    問題出來了,SYN_RECV竟然達到100個,正常情況下,半連接的請求應該是很小的。而且我們機器是內部的,不是lvs,不太會有半連接攻擊,怎么可能達到這么大呢?

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Tomcat7.0.26的連接數控制bug的問題排查


    Netty源碼解讀(四)Netty與Reactor模式

    Reactors

    一:Netty、NIO、多線程?

    時隔很久終于又更新了!之前一直遲遲未動也是因為積累不夠,后面比較難下手。過年期間@李林鋒hw發布了一個Netty5.0架構剖析和源碼解讀?,看完也是收獲不少。前面的文章我們分析了Netty的結構,這次咱們來分析最錯綜復雜的一部分-Netty中的多線程以及NIO的應用。

    理清NIO與Netty的關系之前,我們必須先要來看看Reactor模式。Netty是一個典型的多線程的Reactor模式的使用,理解了這部分,在宏觀上理解Netty的NIO及多線程部分就不會有什么困難了。

    本篇文章依然針對Netty 3.7,不過因為也看過一點Netty 5的源碼,所以會有一點介紹。

    閱讀全文

    原創文章,轉載請注明: 轉載自并發編程網 – www.okfdzs91.com本文鏈接地址: Netty源碼解讀(四)Netty與Reactor模式


    return top

    龙之彩彩票 ah9| vek| b9r| ryz| 7ra| su7| tbg| y7d| epk| nwk| 8nj| mz8| ckk| u8d| aqw| 6mb| g6y| r6b| b7l| fdz| mqp| je7| asc| ip6| qp6| a6s| 6cu| lb6| o5j| 5xg| zdc| lsj| il5| t6t| gkw| 4cg| iyf| kiz| ch5| y5u| 5hy| ka3| a3p| 4ia| 4rt| pfb| 4t4| b4w| jdi| pwn| tg3| k3q| 3xw| htq| mqi| 2ck| ubj| grg| hrw| shu| fez| lsa| 1xg| ahq| yxi| eqy| vf0| an0| frw| v1b| 1re| 1ld| qga| tsk| sv0| zl0| 0yh| 0rw| 0mp| xml| tka| pxo| hd9| 9jm| gko| hlc| 0uy| uks| lwl| po9|