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

Most people do not understand the knowledge points of this "default timeout setting Infinity instance Analysis in Java" article, so the editor summarizes the following contents, detailed contents, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "default timeout setting Infinity instance Analysis in Java" article.

Many libraries package some external communications. Whether it's REST-like API, message queues, databases, mail servers, or anything else. Therefore, you must have some timeout-- for connecting, reading, writing, or idle. Unfortunately, the default timeout for many libraries is set to "0" or "- 1", which means infinity.

This is a very useless and even harmful default setting. There is no actual use case that makes you want to wait for resources forever. And there are a lot of situations that can happen, such as getting stuck at the other end. In the past 3 months, I have had 2 libraries with a default timeout of "infinity", which eventually led to production problems because we forgot to configure them correctly. Sometimes you don't even see the problem until the thread pool runs out.

Never use "Inifinty" as the default timeout. Because your library can cause a lot of production problems. Also note that sometimes the underlying HTTP client (or Socket) doesn't have a reasonable default value-it's still your job to fix it when wrapping it.

What default values should you provide? Reasonable. How about five seconds? You might say that you don't want to impose arbitrary timeouts on users. In this case, I have a better suggestion:

Explicitly requires that the build "client" timeout (because these libraries are usually clients of some external systems). For example, Client.create (url, credentials, timeout). If no timeout is provided, it fails. This allows client users to actively consider what a good timeout is for their use cases-without imposing anything, and most importantly-without risking that the connection gets stuck in production. In addition, you can still provide them with the default option, but still let them choose it explicitly. For example:

Client client = ClientBuilder.create (url) .withcredentials (credentials) .withTimeouts (Timeouts.connect (1000). Read (1000)) .build (); / / ORClient client = ClientBuilder.create (url) .withcredentals (credentials) .withDefaultTimeouts () .build ()

The above builder should ask for "timeout" to be set, and should fail if neither of the methods is called. Even if you don't provide these options, there's at least one good way to specify a timeout-some libraries need reflection to set their underlying client timeout.

I believe this is one of those problems that seem small but can cause a lot of problems in the real world. It can (and should) be solved by the library / client designer.

But since this is not always the case, we must ensure that timeouts are configured every time we use the 3rd square library.

The above is about the content of the article "Infinity instance Analysis of default timeout setting in Java". I believe we all have some understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

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.