Feature request - ability to stop SQS long-polling

[flozano]

It would be great if it was possible to interrupt threads which are waiting in a receiveMessage call. It's really inconvenient when shutting down the application in an ordered way to have to wait for the whole long-poll request to finish.

I tried with thread.interrupt but the request continues.

[fulghum]

Thanks for the feature request Francisco. I'm surprised thread.interrupt doesn't do it; it seems like that's what we'd want to support. We should debug through that and see if we can find some clues.

[fernomac]

Blocking socket reads don't respect Thread.interrupt. Closing the socket (via shutdown() on the client) should do it?

[flozano]

@shorea closing this means it's solved?

[shorea]

Since we haven't heard back I assume you tried @fernomac's suggestion and shutdown the client. If not could you try that and see if it meets your needs?

[davidmoten]

All good! I've just tested this and confirm that shutting down the client cancels the long-poll. An exception is thrown by the long-poll request when client is shutdown like this:

java.lang.IllegalStateException: Connection pool shut down
    at org.apache.http.util.Asserts.check(Asserts.java:34)
    at org.apache.http.pool.AbstractConnPool.lease(AbstractConnPool.java:184)
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.requestConnection(PoolingHttpClientConnectionManager.java:251)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at com.amazonaws.http.conn.ClientConnectionManagerFactory$Handler.invoke(ClientConnectionManagerFactory.java:76)
    at com.amazonaws.http.conn.$Proxy2.requestConnection(Unknown Source)
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:175)
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
    at com.amazonaws.http.apache.client.impl.SdkHttpClient.execute(SdkHttpClient.java:72)
    at com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:895)
    at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:736)
    at com.amazonaws.http.AmazonHttpClient.doExecute(AmazonHttpClient.java:487)
    at com.amazonaws.http.AmazonHttpClient.executeWithTimer(AmazonHttpClient.java:448)
    at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:397)
    at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:378)
    at com.amazonaws.services.sqs.AmazonSQSClient.doInvoke(AmazonSQSClient.java:1750)
    at com.amazonaws.services.sqs.AmazonSQSClient.invoke(AmazonSQSClient.java:1720)
    at com.amazonaws.services.sqs.AmazonSQSClient.receiveMessage(AmazonSQSClient.java:1370)
    at Sqs.main(Sqs.java:74)

[adrian-baker]

It's pretty messy spamming the log with IllegalStateException on shutdown.

eg, let's say your Spring Boot application fails to start up due to another error, and immediately shuts down. A valid, useful exception is now obscured by bad shutdown handling in the AWS SDK.