CODEWITHSUNDEEP
springtcpspring-integration
Wayne
Wayne

Reputation: 13

Non blocking TCP connect in Spring Integration

I am attempting to use Spring Integration to connect to a large number of devices (500-1000) on a volatile network and I'm having issues with the default pool of 10 task schedulers blocking trying to connect to devices that are not currently available.

My implementation is based on the dynamic FTP example, a new child application context is created for each of the remote devices with a client tcp connection factory and tcp inbound adapter with messages routed into a flow of the root context.

The problem I am having is that it is important that these devices are connected quickly, but a large number of them may be offline at any time.

All the connections seem to be sent out to a single 10 member task scheduler pool and end up blocking on the connect call, causing large delays connecting to devices that are online further down the list.

So my question is, is there a way to implement a non blocking connect call using spring integration?

Upvotes: 1

Views: 735

Answers (1)

Gary Russell
Gary Russell

Reputation: 174494

Non-blocking connect won't help because connections are established on demand and the sending thread needs to block until the connection is enabled, especially if it's a request/reply scenario. If you are using channel adapters for one-way or arbitrary two-way communication (not using an outbound gateway). You can put your requests in a queue channel.

The poller resources are limited and it's best to not run long-running tasks on pollers directly, but hand off to as task-executor instead.

You have several options:

  1. Use a task-executor so you don't hold up a poller thread.
  2. Increase the scheduler pool size - either define your own taskScheduler bean, or add a properties file to the classpath /META-INF/spring.integration.properties containing spring.integraton.taskScheduler.poolSize=50 (or whatever).
  3. Reduce the connect timeout from the default on your OS.

The last is a bit more involved and depends on whether you are using NIO or not. If not, provide a custom TcpSocketFactorySupport that returns a factory where createSocket(host, port) actually does createSocket() and connect(socketAdddress, timeout). If you're using NIO, the messages should be buffered and not block until the buffer is full.

EDIT: I see you are using inbound adapters; I assumed they were outbound. I presume you have client-mode set. So there is no task executor option there; but another option is to configure a custom task scheduler into the inbound adapter so you don't use the main pool.

Upvotes: 0

Related Questions