l*****9
发帖数: 9501 | 1 Amazon definitely uses async process: you place an order with wrong credit
card info, you will get order confirmation, then later an email asking you
to fix data.
Async is the architure by choice for large concurrent users, and is LESS
complicated to implement than real-time aproach. Async process is the divide
and conquer approach for complex portal application.
problem
insurance. |
|
b***i
发帖数: 3043 | 2 虽然Async可以解决问题，不等于Sync就没有解决问题的办法。办法之一就是goodbug说
的，这个比Async还简单。但是，CGI连这个简单的办法都不会，更何况Async。 |
|
N********n
发帖数: 8363 | 3
你说的ASYNC和WEB TIER的ASYNC I/O大概不是一回事。WT里面的ASYNC就是
NONBLOCK WAIT，给WEB SERVER缓解THREAD POOL压力用的。这个网站出丑
大概就是把THREAD POOL吃光了。 |
|
n****1
发帖数: 1136 | 4 你说的是与外界的IO是pure nonblocking IO吧, 这个是好东西. python twist也是这
样, 可惜标准库不是.
可是nonblock IO指的是实现, sync/async所指的是接口api, 两者有联系,但nonblock
IO也可以提供sync api, 就像yield这样的. 你用"pure async"这样的词非常容易误导.
async api is terrible to work with, you disagree with that?
"Node也早有了"能给个reference么? 人家python是2001年就有了, 参见 http://www.python.org/dev/peps/pep-0255/ |
|
p*****2
发帖数: 21240 | 5
我是说async的优势在高并发呀。所以现在即使Java也搞async呀。现在不是比较sync和
async吗 |
|
d****i
发帖数: 4809 | 6 公孙侠专业点评不错，请问如果Python3加入原生async支持的话，会不会更进一步和
python2.7不兼容？毕竟JS is born to be async.
async
generator |
|
d********g
发帖数: 10550 | 7 Node的async目前是因为原生而且靠这个主打，所以没错，别的语言如果不是原生的那
在blocking改non-blocking上是需要patch或者重新搞一些库，因为这里比的是按照
Node的规矩来。npm里non-blocking库的支持比较好，因为别的语言之前都不怎么玩这个
Ruby/Java不知道，Python是要搞原生async，至于能不能进一步简化，还得看出来的效
果如何。可以肯定Python的原生async也是比较底层的，之后会在上面有进一步的
framework，慢慢搭 |
|
d********g
发帖数: 10550 | 8 好虫对蜥蜴鼓吹的vert.x发起猛攻。主要观点：
1. JVM主要是Java自己玩，没几个主流语言在JVM上run更别说抗衡了
2. Java world对async没有不明觉厉（多线程不灵或者没有的更欢迎async例如Python
和JS，Java不着急，这是事实）
3. vert.x不会是主流，结局堪忧
蜥蜴观点：
1. JVM统战一切，只要沾了JVM就得道升天
2. vert.x会吸引别的语言的人
3. vert.x这个没多久前才发现的新玩具是人类的救星，之前鼓吹的那些都不算了
两人观点针锋相对，只是好虫碍于Java面子从来不当面驳斥蜥蜴。拭目以待vert.x能撑
多久
发信人: goodbug (好虫), 信区: Programming
标 题: Re: vert.x 基本上没戏
发信站: BBS 未名空间站 (Tue Jan 28 16:19:03 2014, 美东)
出了java.现在主流语言有几个在jvm 上run啊。
我评论的是他这句话。
其实java world并不是那么在意async，否则netty之上早就一堆东西了。akka迄今也没
火。
vertx估计结局也... 阅读全帖 |
|
z****e
发帖数: 54598 | 9 一般的db缺省都是sync的吧
哪有上来就async的道理
顶多说是可以通过某一种setting调整成async的
见的最多的都是sync，然后可以调整成async的
redis没用过，不知道，但是我怀疑这是二爷的忽悠 |
|
l**h
发帖数: 893 | 10 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
response。
没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
服务器开的线程要轻量级很多？ |
|
x****d
发帖数: 1766 | 11 楼主可能混淆了两种情况
只讲单纯http request，不说websocket xmlhttp/ajax，
1，request进来如果不做什么复杂的事情马上就回去了
2，request进来等比如数据库返回结果，假设等一分钟，
第二种情况不管你用node还是用tomcat/java都不关web server的事，
node只是一个web server，
weblogic/websphere 对第二种情况有专利的处理办法
如果自己做可以用jms连两个servlet，
处理request的servlet
把进来的request排队，
有结果了第二个response servlet按顺序返回结果回去
这个跟node没关系，和通常说的web server没关系
用node也可以这样处理长时间等数据库的请求
第一种情况，理论上请求多了也回堵车，
但实际上是不可能的，sync还是async其实都很快，
如果request多到要堵车，现实中这样的应用，
前面会有loadbalancer，
有reverse proxy，根本不用web server操心，
前面路由器都先死掉了，不会堵在node或者to... 阅读全帖 |
|
a*****e
发帖数: 1700 | 12 我什么时候说过 inversion of control 和 async 有关系？我说的是：
1. "callback 反人类" 是因为 "inversion of control"
2. nodejs 鼓吹的 async programming 和 callback 没有一毛钱关系，用 co-routine
一样可以做 async，而且早很多年就被做过了。强迫用户使用 callback 是 nodejs
的设计者脑残。
3. continuation 是实现 co-routine 和 event-driven 之间转换的核心方法。你前面
说的 promise 和 generator 什么的，都属于 imitation of co-routine |
|
a*****e
发帖数: 1700 | 13
以下来自 Wikipedia 字条：
"Inversion of control carries the strong connotation that the reusable code
and the problem-specific code are developed independently even though they
operate together in an application. Software frameworks, callbacks,
schedulers, event loops and dependency injection are examples of design
patterns that follow the inversion of control principle, although the term
is most commonly used in the context of object-oriented programming."
Callback 之所以难以使用，直接原因就是因为 inversion of contr... 阅读全帖 |
|
l**********n
发帖数: 8443 | 14 async = require('async')
async.parallel([
function(callback){
for (var i = 0; i < 1000000000; i++) /* Do nothing */;
console.log("function: 1")
},
function(callback){
console.log("function: 2")
}
]);
what result you expect? |
|
l**********n
发帖数: 8443 | 15 async = require('async')
request = require('request')
async.parallel([
function(callback){
request("http://google.jp", function(err, response, body) {
if(err) { console.log(err); callback(true); return; }
console.log("function: 1")
callback(false);
});
},
function(callback){
request("http://google.com", function(err, response, body) {
if(err) { console.log(err); callback(true); return; }
console.log("function: 2")
call... 阅读全帖 |
|
d****n
发帖数: 1637 | 16 你这个 写法block了， wrap each task in setImmediate and try minimize each
task size
async = require('async')
async.parallel([
function(callback){
setImmediate(function(){
for (var i = 0; i < 1000000000; i++) {;}/* Do nothing */;
console.log("function: 1")
callback();
});
},
function(callback){
setImmediate(function(){
console.log("function: 2");
callback();// you missed callback here,不用谢了 :)
});
}
]);
另外：这... 阅读全帖 |
|
z****e
发帖数: 54598 | 17 相对不容易
其实总体而言都很容易
但是有骗子说vert.x scale会有问题嘛
这个一看就是胡扯蛋，那既然要比较难易度
那显然是vert.x容易scale啊
最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
全部自动搞定，node就需要自己弄了
而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
async其实跟语言无关，甚至跟运行环境都没有太大关系
换个语言一样用async，哪怕是python, ruby都可以做到
甚至perl，可惜骗子领悟能力太低，看不懂
其实immutable跟语言本身也是无关的
把context看完整 |
|
z****e
发帖数: 54598 | 18 相对不容易
其实总体而言都很容易
但是有骗子说vert.x scale会有问题嘛
这个一看就是胡扯蛋，那既然要比较难易度
那显然是vert.x容易scale啊
最简单的，我把cpu从一个core弄成多个cores，vert.x不用做任何修改
全部自动搞定，node就需要自己弄了
而且同样能够handle async的情况，前面我说js能够直接用在vert.x上就是告诉某些骗子
async其实跟语言无关，甚至跟运行环境都没有太大关系
换个语言一样用async，哪怕是python, ruby都可以做到
甚至perl，可惜骗子领悟能力太低，看不懂
其实immutable跟语言本身也是无关的
把context看完整 |
|
B********r
发帖数: 397 | 19 艾玛不懂还骂人？
async的实现就是用的Task（c#）／Future（java）， 这两个都是在thread基础上，
只不过multi task share same thread，你去看看人家source code再来扯
即使是单个request，non－block IO 也是要的，只不过一样可以用thread pool来代替
zhaoce 说的没错，java servlet用的thread pool一样跑的快，node.js即使用了async
，除了io 能够真正non－blocking其它更慢，还要context switch
游戏的异步就是因为request多而且杂，其中io等待时间长，而维持大量的thread pool
太消耗资源
普通server async 和multi threading 没啥区别 |
|
z****e
发帖数: 54598 | 20 你说得没错，thread一样做async，而且这正是java8的改进方向
关键在于脚本无法启动thread，导致thread和process绑定
绝大多数资源都丢给process去浪费了，能够自由控制thread的语言强势多了
能够做出更为强大的framework，比如vert.x
补充一点，你说的future那个稍微有些落伍
lambda出来之后，可以不用future了，可以focus在以lambda为重点的callback上
这样就能实现真正的async了，以前future需要wait，这就有block
async
pool |
|
b***e
发帖数: 1419 | 21 Handling of async calls should happen on a worker server that is separated
from the web server that's handling the web requests. So calling an async
job usually is a push of a message to a job queue. Seems in your
application model, you're trying to run the async job on the web server
directly. This can be done, and sometimes for internal tools or dev
environment we do that. But in production environment it is not generally
recognized as the best practice. |
|
W***o
发帖数: 6519 | 22 以前写过一个类似的，就是先找儿子，再给每个儿子找儿子：
var async = require('async');
var parentLaoWang = "Lao Wang"
if (parentLaoWang) {
var laoWangFamily = {"laoWang": []};
var findKidByParent = function(parent, callback) {
//findKidsByParent is a custom function on Kids collection
Kids.findKidsByParent(parent, function (err, foundKids) {
//foundKids is Array
if (foundKids) {
var currParentAndKids = {"parent" : parent, "kids" :
foundKids};
la... 阅读全帖 |
|
|
k****i
发帖数: 101 | 24 - non-blocking(async) i/o 底层先要支持，如epoll等
- 应用层有多种实现，node用single threaded eventloop，go用goroutine，c#有
async/await，java有threadpool如某些async client libs，也有eventloop如vertx，
这些都能解决io-bound request/connection:thread=1：1的问题。 |
|
k******e
发帖数: 19 | 25 很少需要用到softreference, weakrefernce or phantomreference，一般是在你需要
cache一堆东西，比如说图片，的时候会要用到。但是强烈建议不要自己重写image
cache一类的东西，用Picasso或者Fresco什么的比较成熟的东西。有时候有人也喜欢用
weak reference去包装一个context object，比如说activity什么的以避免前面说的“
小心leak context”的问题。
但是很多时候这都是可以用别的办法达成，比如说那个weak reference wrap activity
，一般都是用async task的时候在task完成后的callback里要update UI，用这个避免
activity在async task没完成前就被释放了。但是这种做法是比较老式的做法，现在很
多新的pattern都会用个service（一般用intent service）去完成放在async task里的
任务，完成后可以用local broadcast manager发布个公告，在activity里面register
... 阅读全帖 |
|
c*********e
发帖数: 16335 | 26 waterfall是async 1 -> async 2 -> async 3... |
|
h**********c
发帖数: 4120 | 27 你可以理解在传统的操作系统下这是一个infinite loop，in fact, kind of race
condition.
BUT
在up-to-date操作系统，文件系统下的async io，很可能是无法预见的正如死锁不一定
就总是发生甚至无法重构发生的环境，昂贵的服务器，特定的licensed软件。
那么在async 条件下，如果一个文件dscriptor被锁，我的理解是当前进程的请求被挂
起，系统以新的线程继续grep 其他的未见。按传统的理解keyword1,keyword2,
keyword3顺序出现，但在async条件下行为将是无法预测的。很有可能在不远的将来，
而且已经发生，what you take for granted will surprise you.
希望对xfs等吃比较透的同学展开讨论 |
|
c*********e
发帖数: 16335 | 28 凡是用future.get()来做async的都是耍流氓。
node.js的non-blocking i/o才是正宗的one thread, async. 它用callback来处理数据。
future.get()需要block thread来等待结果，不能算真正的async.
nio和rxjava都是用的future.get()。
看来java真的步了c++的后尘，搞出个concurrency,但是multi-threading的bug是极其
难以找到的，有的只在大量请求的时候才会出现。当年的c++,也是搞出些自以为很高难
度的东西，结果曲高和寡，没人用了。现在java也到了这一步。历史总是惊人的相似。 |
|
w*s
发帖数: 7227 | 29 打开页面localhost:8080/db1, 页面停滞不动。
server端打印出step 1, step 2, 但没有step 3.
请问为什么？谢谢！
主程序main.js
const express = require('express')
const app = express()
const port = 8080
var db1 = require("./db.js");
app.get('/', (request, response) => {
response.send('Hello from Express!')
})
app.get('/db1', (request, response) => {
var q1 = db1.query1(function(){
console.log("step 3: " + q1);
response.send('Hello from db1! ' + q1);
});
})
app.listen(port, (err) => {
if (err) {
return ... 阅读全帖 |
|
f****y
发帖数: 243 | 30 菜鸟借坑问下啊。。。
像在那种老的环境下，async这种东西怎么实现效率高一点啊？我手开线程写出来的异
步效率跟shit一样。。。
C++11里对于async的支持也就一个future，然而也并不能完全实现async的直接调用，
还是要写中间件的样子？
对于tornado和node里的异步，epoll这种机制的效率真的就是最高么。。。 |
|
d********g
发帖数: 10550 | 31 3.4+主要是asyncio相关。Python 3.4开始内置asyncio，3.3还需要额外装库。3.5加入
async/await语法，3.6更是把async/await推广到其它地方比如generator：
https://docs.python.org/3/whatsnew/3.5.html
https://docs.python.org/3/whatsnew/3.6.html
3.6的dict也重新实现了，性能提升内存占用下降的同时，带来的一个副产品是dict现
在也可以直接当OrderedDict用了，虽然这个特性还没有正式在API上确认
在公司还用Python 2.7很正常，但是自己写新项目还用2.7就是自己给自己挖坑了。这
两个版本我都写，自己的非开源项目反而故意不要语法兼容（比如能用高版本async/
await的就绝对不用低版本兼容的yield），强制跟上3.x的升级，这样以后的维护坑会
更少
别的不说，Python 2.7里经常需要from __future__ import absolute_import,
unicode_literals等，这都是2.x设计缺... 阅读全帖 |
|
d********g
发帖数: 10550 | 32 那是它自己代码没写好，又不怪语言。本来这都是交给SDK做的，Win里编程最典型一个
要弹一个progress bar同时又要支持响应就不能用modal，因为modal是blocking的。大
多数语言本身最开始都是sync的，要实现async不是在语言层面。JavaScript是个例外
因为最开始它的主要目的就是为了浏览器UI的简单交互
语言层面是说比如C++11加入的async、Python 3加入的yield from、async/await等
PyQt不是在语言层面，就是SDK的事 |
|
x***4
发帖数: 1815 | 33 我个人感觉：
FP和immutable data能够让相当一部分业务逻辑容易理解，也容易测试。
但是用FP写async也不比callback hell好太多，还是非常繁琐难理解。
async/await，coroutine能让你的code长得跟同步的code差不多，能让async程序白菜
化。
最后插一句，static typing，容易做refactoring，bug也小。
所以我最喜欢fp+static type+coroutine。 |
|
B*D
发帖数: 5016 | 34 这个不对。
CD的编码有奇偶校验的部分。
你指的失真，如果是error。由于校验的存在，无论是CD机或者说抓轨都是很罕见的。
出现error的情况，就是听起来有爆裂pop声，一般是CD盘有裂纹等造成的。比如以前的
打口碟。
在数据正确的情况下，普遍认为对音质造成损害的就是时基误差/jitter。
因为CD数据本身不含有时间码。所以怎么避免各种类型的jitter就是一个比较复杂的问
题。
这个link中，有一些好的paper解释这个Jitter对音质和失真的影响的。
http://www.whatsbestforum.com/showthread.php?2195-WBF-Library-A
在以前，品质良好的CD机，有好的线性电源。高素质的晶振和DAC，和稳定的读盘机构。
音质肯定要超过电脑或者SoC类别的数字讯号源。
但是出现了Asynchronous USB/Firewire模式以后。电脑等讯号源输出音频数据到独立
DAC。
在Asyncchronous模式下，电脑只是输出音频数据的slave，时钟依赖于独立的DAC，不
受到电脑的任何干扰。
这样就避免了电脑劣质的开关电源等一些问... 阅读全帖 |
|
d********g
发帖数: 10550 | 35 Python在做built-in的async支持，一时半会儿还好不了。现在通用一点的就twisted和
gevent吧，但是twisted的历史负担比较重。tornado不是通用的async库，我也没做过 |
|
s*w
发帖数: 729 | 36 大牛说的对，这个是很原始，应该尽量用 async, packaged_task，我理解你的意思,
接下来就用 async 来试试
不过那是高级阶段了，学习的时候能想明白多线程里面的很多问题还是挺好的，总不能
面试的时候回答我不知道为啥他们醒不来 |
|
g*****g
发帖数: 34805 | 37 Multi-threaded async means you still need to worry about locks if the logic
requires that. It's not necessarily an advantage. Node has some handy
libraries that are pure async, on Java side, many libraries, including JDK
and spring already have synchronized block and ThreadLocal in it. So you do
need be cautious on the libraries you are using. |
|
j********x
发帖数: 2330 | 38 很多人以为算法就是做题时候那些东西，这个也没错。但是算法需要应用到更加切实的
工作当中：
1. 系统选型，流程设计；很多时候为了省事用的都是非常傻逼的算法；稍加改进就能
大幅提高性能，没有扎实的算法功底是做不到的
2. 后期维护，重构；对算法的要求也不低。
3. 软件工程，代码组织结构；代码写的快，写的美，都是次要的；扩展性好、健壮、
可维护的代码才是品质最好的代码。这些都不是做两道题、看几本书能体会的，必须是
经过必要的工程实践，加以总结才能掌握
4. 理解和掌握一两门基础技术，有助于紧跟时代技术潮流；别看各种新技术很多，其
实都是很多老技术的翻新，像node这种，就是async+js；async的历史都可以追溯到计
算机诞生了。神马go，不就是c+一些语法糖么，go的编译器出资plan9，老了吧唧的东
西；想erlang这种大规模分布式计算的模型，都诞生几十年了；map reduce这种东西，
放在20年前都是被人笑掉大牙的糙货。。。 |
|
z****e
发帖数: 54598 | 39
no，我说的是真的
如果你在payment gateway混过的话
从netty什么开始写
东方剑桥是搞jboss的
跟写netty那个韩国人搞不好都互相认识
这个分量应该他更清楚
很多搞payment gateway的公司
早过vert.x5-6年就制造出类似vert.x的一个内部系统了
大谈async这些，node那都是后来的事了
java要搞async，最早就是netty |
|
w*****e
发帖数: 931 | 40 看了一下好像是chrome的ad blocker造成的，导致
Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
关掉ad blocker就好了。 |
|
|
l*s
发帖数: 783 | 42 ☆─────────────────────────────────────☆
Cklein (Calvin Klein) 于 (Mon Aug 6 20:03:32 2012, 美东) 提到:
从事IT将近20年, .NET出生前就开始研究.NET, 我可以大言不惭的说我是.NET 牛人了.
可是对.NET的近期发展很是失望.
.Net 2.0 在语言上已是顶峰. LinQ 是一个VERY NICE数据库工具.
时至今日, 我的标准配置还是:
.Net 3.5 SP1, Linq2Sql, ASP.NET, WCF
其它后来所有的新版本, 新FEATURE, 感觉都有点脱裤子放屁. .NET4.0 我研究了很长
时间, 还是觉得没有必要升级. 没有任何新的东西.升级风险很大, 得不偿失.
EF也做的越来越臃肿, 复杂. LINQ 2 SQL足够了.
MVC也扯淡. ASP.NET本来不是MVC的东西, 硬要用这个基础做一个MVC出来. 要做干脆另
起炉灶, 现在搞得不伦不类, 太像业余选手. 还搞不同的SCRIPTING ENGINE, 感觉象业
余的OPENSOURCE... 阅读全帖 |
|
N********n
发帖数: 8363 | 43
07年WPF推出时XAML就是指定的MARK UP LANGUAGE。后来在WPF基础上做了
SL，所以WPF和SL一直是以XAML作班底。这样从SL转移到METRO很容易。
METRO实际上是SL6, 但是不许再做跨平台的PLUG-IN了, 否则SS要发飙。
CLR仍然是METRO的重要组成，否则在RT里面就没法用.NET 4.5那些ASYNC支
持了。感兴趣的话可以去看今年的BUILD VIDEOS，有解释.Net, CLR是怎样
在WIN8和PHONE8上被使用的SESSION，EASY ASYNC是一大主题。
http://www.mitbbs.com/article_t/DotNet/31106401.html |
|
|
y*******n
发帖数: 10103 | 45 看上去AMD混的很惨。但事实上如果包括主机在内的话，游戏GPU市场占有率，AMD是绝
对优势，90%以上吧。NV事实上只能在PC高端占有优势。
游戏公司在设计一款AAA游戏时必先首先考虑基于console，毕竟这是大部分利润的来源
。Console已被AMD的GCN显示架构所垄断。
最近新游戏Quantum break在N卡下的表现之差，980ti被390干翻，可见一斑。
就连PC上的dx12也是主要基于AMD的mantle而来。DX12下，A卡都跟打了鸡血一样。N卡
不升反降。这里重要的原因是DX12的重要特性Async Compute这个技术N卡在硬件上就没
有考虑到，传言说甚至在几个月后发布的Pascal显卡上可能都没有办法在硬件上实现
Async Compute。我看这玩意就是为GCN量身定做的。而A卡从2011年的GCN1.0就已经支
持这个特性。
可以想见在dx12游戏普及后，N卡的日子不会太好过。PC高端那个位数百分比的N卡用户
，游戏公司没有动力去优化。 |
|
g*****g
发帖数: 34805 | 46 写框架.写从Server Socket开始实现的Server，或者基于Async IO的类库，如Netty
，Ning Async HttpClient等的server。这种活一般而言新手是没有机会接触的。
Swing之类的也有一些，大多比较简单，就是2-3个线程同步。
大部分Java工作需要一点多线程的知识，但是在框架之下，需要直接写的不多。
至于什么公司招这种人。主要还是大公司，比如苹果做icloud就很缺这方面的人，有朋
友说一直找不到合适的。你可以去看他们的广告。 |
|
o**2
发帖数: 168 | 47 我完全没有被offensed，你讨论的态度非常positive and professional。
关于我对executor framework的看法，我已经在和goodbug的讨论中(link below)陈述
过了。（goodbug silently退出了讨论。）
FMP vs ExecutorService/Future
http://www.mitbbs.com/article_t0/Programming/31258897.html
简单地说，我的意见和你的相左。Java executor framework比不上C#的async keyword
，就按你说的限制在Java之内的话，也比不过Spring Framework的@Async。
至于你提到的硬件加速等performance boost，那是FMP不care的东西。因为FMP卖的是
spec是标准，你没有注意到我的project是自称为reference implementation吗？
就象C不会去和汇编比速度、也不会自称是汇编代码的management一样，FMP也是自成体
系的。FMP追求的重点是降低程序员写并... 阅读全帖 |
|
d****i
发帖数: 4809 | 48 Jersey 2.0加入了对Async的支持，但是一般情况下不需要用。
https://jersey.java.net/documentation/latest/async.html
“ This model (Synchronous mode) is typically sufficient for processing of
requests for which the processing resource method execution takes a
relatively short time. However, in cases where a resource method execution
is known to take a long time to compute the result, server-side asynchronous
processing model should be used. ” |
|
d****i
发帖数: 4809 | 49 Jersey 2.0加入了对Async的支持，但是一般情况下不需要用。
https://jersey.java.net/documentation/latest/async.html
“ This model (Synchronous mode) is typically sufficient for processing of
requests for which the processing resource method execution takes a
relatively short time. However, in cases where a resource method execution
is known to take a long time to compute the result, server-side asynchronous
processing model should be used. ” |
|
