zhengyangyong commented on a change in pull request #47: General development
dir translation and include img
URL:
https://github.com/apache/incubator-servicecomb-docs/pull/47#discussion_r212553742
##########
File path: java-chassis-reference/en_US/general-development/reactive.md
##########
@@ -34,45 +34,45 @@ public String hello(@PathVariable(name = "name") String
name){
}
```
-与此对应的处理流程如下：
+The corresponding processing flow is as follows:
-根据这个流程的特点，可以看到会产生以下结果：
+According to the characteristics of this process, you can see the following
results:
-* 因为是同步调用，在“Other microservices”未应答之前“Microservice A”的调用线程一直处于阻塞等待状态，不处理任何其他事务
+* Because it is a synchronous call, the calling thread of "Microservice A" is
always in the blocking wait state before "Other microservices" is not answered,
and does not process any other transactions.
-* 当Executor中所有线程都在等待远程应答时，所有新的请求都只能在Queue中排队，得不到处理，此时整个系统相当于停止工作了
+* When all threads in the Executor are waiting for a remote response, all new
requests can only be queued in the Queue and cannot be processed. At this
point, the entire system is equivalent to stop working.
-*
要增加处理能力，只能增加Executor中的线程数，而操作系统并不能无限地增加线程数，事实上增加线程数带来的收益是一个抛物线模型，超出一定的临界值后，系统的处理能力其实会下降，而这个临界值并不会太大
+* To increase the processing power, only increase the number of threads in the
Executor, and the operating system can not increase the number of threads
indefinitely. The benefit of increasing the number of threads is a parabolic
model. After a specific critical value, the system handles The ability will
drop, and this threshold will not be too big.
-* 当业务逻辑中，需要多次进行远程同步操作时，会更加恶化这个现象
+* This phenomenon is exacerbated when the remote synchronization operation is
required multiple times in the business logic.
-## 嵌套同步调用的“错误”优化：
+## "Error" optimization for nested synchronous calls:
-针对前一场景，有人会认为将“Invoke producer method”丢进另一个线程池，可以解决问题，包括以下处理方式：
+For the previous scenario, someone would think that throwing the "Invoke
producer method" into another thread pool can solve the problem, including the
following:
-* 在producer method打标注@Async，由AOP负责将对该方法的调用丢进其他线程池去
+* In the producer method, mark @Async, which is responsible for throwing the
call to the method into other thread pools.
-* 在producer method内部通过业务代码转移线程
+* Transferring threads through business code inside the producer method
-形成以下流程：
+Form the following process:
-根据这个流程的特点，可以看到会产生以下结果：
+According to the characteristics of this process, you can see the following
results:
-* “Invoke producer method”必须立即返回，否则Executor线程还是得不到释放
+* "Invoke producer method" must be returned immediately, otherwise, the
Executor thread will not be released
-* “Invoke producer method”必须提供一个新的机制告知调用流程自己的返回值，不是最终返回值（当前没有这个机制）
+* "Invoke producer method" must provide a new mechanism to inform the calling
process of its return value, not the final return value (currently no such
mechanism)
-* 虽然Executor线程释放了，但是Customer
Executor，其实还是阻塞住，在等待远端应答，整个系统的阻塞状态并没有得到改变；而且还凭空多了一次线程切换
+* Although the Executor thread is released, the Customer Executor is blocked,
waiting for the remote response, the blocking state of the entire system has
not changed, and there is one more thread switching out of thin air.
Review comment:
这段改一下，不用原文机翻。。。
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
