Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to use Netty to realize multiplexed client". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

Netty provides only asynchronous data transfer, but does not implement multiplexed clients.

A distributed client code basically looks like this:

public Response sent(final Request request) { channel.writeAndFlush(request); return clientChannelInitializer.getResponse(request.getMessageId()); }

First send a request to the server through the channel, and then wait for the server to return the result.

But Netty is asynchronous, writeAndFlush this method, just tell the server, I want to send data, and then immediately return. So calling getResponse directly at this time will not get the value. Because netty writes the return value inside the callback.

The workaround is to use BlockingQueue to receive the returned data. Once BlockingQueue has data, take it out. If there is no data, wait.

In single-threaded environments, this is fine. This ensures that Netty clients are accessed by only one thread. If there are multiple threads accessing simultaneously, it is possible that the return value of the second thread is obtained by the first thread due to asynchronous reasons. For example:

Thread A sends requests using client

Thread A fetches data from BlockingQueue. Queue is empty and thread A waits.

server accepts and opens a thread to process request A

Thread B uses client to send requests

Thread B fetches data from BlockingQueue. Queue is empty and thread B is waiting.

server accepts and opens another thread to process request B

Thread B's request processing speed is faster, return first

client writes the return value B to BlockingQueue

BlockQueue has data, thread A takes to data, but is the result of thread B

This results in a mismatch between request and response.

There are three ways to solve this problem.

Using short connections, a new client is requested each time, and the client is closed after receiving the response. The disadvantage of this is obvious, this is equivalent to http server, can not play the advantage of long connection of intranet.

Using connection pool, take a client from the connection pool at a time, and return the client to the connection pool after receiving the response. This is a bit like a database connection pool. There are no drawbacks to this approach, but you need to implement your own connection pool.

Use a single client, but generate a unique messageId in the request, which can be nanoTime. Then, after the server finishes processing, the messageId is also returned in the response. In this way, instead of maintaining a BlockingQueue, the client maintains a ConcurrentHashMap, where key is messageId and value is an empty BlockingQueue. When client sends resquest to server, write messageId in Map and instantiate a BlockingQueue (size can be 1 for optimization). Then wait for this BlockingQueue to have a value. In the callback method that receives the response, extract the blockingQueue value according to the messageId, and then delete the Key.

I implemented the third method myself. For the specific code, please see:

https://github.com/terrymanu/miracle-framework/tree/master/miracle-framework-remote/miracle-framework-remote-netty

"How to use Netty to implement multiplexed clients" content is introduced here, thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.