Two small lessons about resource pooling

"Do not use a global resource pool. Unless you really know it's reasonable to configure--such as size, timeout, etc. ”

I've stepped on this hole twice.

The first time is the connection pool for HTTP. I used a default Poolinghttpclientconnectionmanager to make a rest service call. Unexpectedly, in the default configuration of the HTTP connection pool, the same domain name creates up to two links. As a result, a little bit of pressure came to a tragic moment.

The second time is the thread pool. Spring's Task:annotation-driven configuration will place the global @async annotation class/method and the scheduled task in the same thread/task pool for asynchronous invocation. As a result, a large number of multithreaded operations in the system timed out when some of these tasks blocked the worker thread.

Apart from the two pits, I succeeded in avoiding a pit.

When running multi-threaded tasks using Java 8 's parallel stream, by default all threads are dispatched and run by Forkjoinpool.commonpool (). Similar to what I did when I stepped on the second pit: if there are certain tasks blocking the worker thread, other multi-threaded tasks will pay extra waiting time or even timeout.

This time I used a custom forkjoinpool to escape the pit. And I remind myself that when you use a global resource pool, you must be cautious. For example, the global thread pool, http/db connection pool, cache pool, and so on. Because the coverage and impact of the "global" are too broad, the unintentional loss of one place can lead to hundreds of problems. Such risks are too big and too uncontrolled.

However, database connection pooling is considered a special case. In fact, the database connection pool also has these risks, but in most cases, our database connection pooling mechanism research and size, time-out and other aspects of the configuration has been relatively complete, so there is little impact on application services. In addition, because the database operation is too frequent, database connection pool is a just need, not it.

The distinction between using resource pools can play a role in problem isolation. However, too many resource pools can sometimes cause waste of resources. Although the probability of this situation will be smaller, but once there is a real problem, it is not so easy to locate and solve it.

My experience is to differentiate between types of operations (CPU intensive operations, database read and write operations, network IO, hard disk IO, etc.), using different resource pools for different types of operations (such as different thread pools), and for the same type of operations, you can subdivide (such as intranet io, extranet IO, etc.), and use different resource pools as a basis for this.

But all in all, don't use a globally uniform resource pool.

This article is from the "Programming Capricorn Man" blog, make sure to keep this source http://winters1224.blog.51cto.com/3021203/1885296

Two small lessons about resource pooling