Skip to content

Commit 08e0187

Browse files
committed
Corrections
Signed-off-by: Rafael Ibasco <[email protected]>
1 parent d915b9e commit 08e0187

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

site/markdown/introduction.md

+4-3
Original file line numberDiff line numberDiff line change
@@ -56,7 +56,7 @@ Other supported protocols
5656

5757
### Best Practices
5858

59-
Keep in mind that you should **NEVER BLOCK** the thread of your completion handlers. If you have to perform synchronization within your handlers/callbacks, then it is highly recommended that you execute them asynchronously, otherwise your application may
59+
Keep in mind that you should **NEVER BLOCK** the thread of your completion handlers. If you have to perform synchronization or a long running operation within your handlers/callbacks, then it is highly recommended that you execute them asynchronously, otherwise your application may
6060
hang indefinitely.
6161
Java's [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) provides a convenient way of executing your handlers asynchronously. Refer to the working examples below.
6262

@@ -254,10 +254,11 @@ public class RecommendedExampleOne {
254254
}
255255
```
256256

257-
The problem with this approach is that its not efficient. A closer look at the `parseOutput` implementation, shows that it is calling `client.execute(...).join()` synchronously. The call to `join()` blocks the current thread until a response is received. A slightly better approach would be to execute all these additional requests asynchronously then use a synchronization barrier (e.g. `CountDownLatch` or `Phaser`) to block until all requests have been fulfilled. In this example, we will
257+
The problem with this approach is that it's not efficient. A closer look at the `parseOutput` implementation, shows that it is calling `client.execute(...).join()` synchronously and will block the current thread until the method completes. The call to `join()` blocks the current thread until a response is received. A slightly better approach would be to execute all these additional requests asynchronously then use a synchronization barrier (e.g. `CountDownLatch` or `Phaser`) to block until all
258+
requests have been fulfilled. In this example, we will
258259
use `Phaser` since we do not yet know how many cvars we are going to process.
259260

260-
**Solution 2:** Update `parseOutput` implementation so that we requests for `help <cvar>` are all executed asynchronously then wait until all requests have been fulfilled.
261+
**Solution 2:** Update `parseOutput` implementation so that the requests for `help <cvar>` are all executed asynchronously then wait until all requests have been fulfilled.
261262

262263
```java
263264
import java.util.concurrent.CompletableFuture;

0 commit comments

Comments
 (0)