0

I have read another issue in this website like this but I don't get how to resolve the issue.

Spring Integration: Application leaking SimpleAsyncTaskExecutor threads?

My error is similar to previous link

SimpleAsyncTaskExecutor-2327" - Thread t@2405
java.lang.Thread.State: WAITING
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for <7a224c1> (a java.util.concurrent.CountDownLatch$Sync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
    at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
    at org.springframework.messaging.core.GenericMessagingTemplate$TemporaryReplyChannel.receive(GenericMessagingTemplate.java:199)
    at org.springframework.messaging.core.GenericMessagingTemplate$TemporaryReplyChannel.receive(GenericMessagingTemplate.java:192)
    at org.springframework.messaging.core.GenericMessagingTemplate.doReceive(GenericMessagingTemplate.java:130)
    at org.springframework.messaging.core.GenericMessagingTemplate.doSendAndReceive(GenericMessagingTemplate.java:157)
    at org.springframework.messaging.core.GenericMessagingTemplate.doSendAndReceive(GenericMessagingTemplate.java:45)
    at org.springframework.messaging.core.AbstractMessagingTemplate.sendAndReceive(AbstractMessagingTemplate.java:42)
    at org.springframework.integration.core.MessagingTemplate.sendAndReceive(MessagingTemplate.java:97)
    at org.springframework.integration.core.MessagingTemplate.sendAndReceive(MessagingTemplate.java:38)
    at org.springframework.messaging.core.AbstractMessagingTemplate.convertSendAndReceive(AbstractMessagingTemplate.java:79)
    at org.springframework.messaging.core.AbstractMessagingTemplate.convertSendAndReceive(AbstractMessagingTemplate.java:70)
    at org.springframework.integration.gateway.MessagingGatewaySupport.doSendAndReceive(MessagingGatewaySupport.java:449)

I'm using

  • spring-integration-java-dsl-1.2.3.RELEASE
  • spring-integration-ip-4.3.17.RELEASE
  • spring-integration-http-4.3.17.RELEASE

My scenario is the next: I receive a message throught a Api Controller and this message is sent a un TCP socket.

I have defined a MessageGateway interface

@MessagingGateway(defaultRequestChannel = "toTcp.input")
public interface MessageTcpGateway {

@Gateway
public ListenableFuture<Void> sendTcpChannel(byte[] data, 
 @Header("connectionId") String connectionId );
}

After I use this interface in a service class like this:

public void sendMessageTcpGateway(final String bridgeId,final String connectionId, final byte[] message) {
    LOGGER.debug("sendMessageTcpGateway connectionId:{} - message:{}", connectionId, message);
    if (holder.existsConnection(connectionId)!=null) {
           gatewayTcp.sendTcpChannel(message,connectionId);
    } else {
        LOGGER.error("Not send message connectionId:{} - message:{}", connectionId, message);
    }
}
  1. Why the thread is waiting ?. Is my process waiting for any kind of sign and I'm not considered?. I guess that if the connection is not available or whatever kind of error, spring-integration will throw a exception

  2. How can i resolve this issue?

Reyfren
  • 51
  • 1
  • 6

1 Answers1

0

I wonder why don't follow recommendations from that SO thread... The ListenableFuture<Void> is a bottleneck in your solution. As you see by stack trace you have there doSendAndReceive(), but I guess your target solution is really one-way and doesn't return anything for the replyChannel in headers.

You should consider to have just plain void return type and an ExecutorChannel downstream.

Unfortunately we can't detect such a situation from the framework side since a Future return type of the gateway method indicates that you are going to perform request-reply async manner. In your case it is just an async request, nothing more.

Artem Bilan
  • 113,505
  • 11
  • 91
  • 118