Open connections are leaking

[neongreen]

I do a bunch of SQS.deleteMessages in a loop, and experience long waits (5-10 seconds) after getting 99 open connections. This happens with https://github.com/iain/fake_sqs (I haven't tested with real SQS).

This behavior is introduced by a recent commit (made after 1.6.0 was released): 2688190.

My guess is that in the absence of finalizers in conduit-1.3, nothing is closing connections open by Responses. The following diff fixes the behavior of deleteMessage for me:

diff --git a/core/src/Network/AWS/Response.hs b/core/src/Network/AWS/Response.hs
index 4791de6a3c..907b0faa05 100644
--- a/core/src/Network/AWS/Response.hs
+++ b/core/src/Network/AWS/Response.hs
@@ -45,8 +45,9 @@ receiveNull :: (MonadResource m, MonadThrow m)
             -> Proxy a
             -> ClientResponse
             -> m (Response a)
-receiveNull rs _ = stream $ \_ _ x ->
-    liftResourceT (x `connect` pure (Right rs))
+receiveNull rs _ = stream $ \_ _ x -> do
+    sinkLBS x
+    pure (Right rs)

 receiveEmpty :: (MonadResource m, MonadThrow m)
              => (Int -> ResponseHeaders -> () -> Either String (Rs a))

It's still slower than it used to be (I've no idea why), but at least it doesn't leak connections anymore and I get no stuck requests.

Other receiveBlah functions might also be affected.

[naushadh]

Perhaps sinkNull would be quicker?

[neongreen]

Perhaps. I didn't know it existed.

…

On Sep 19 2018, at 11:40 pm, naushadh ***@***.***> wrote: Perhaps sinkNull (http://hackage.haskell.org/package/conduit-1.3.0.3/docs/Data-Conduit-Combinators.html#v:sinkNull) would be quicker? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#490 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABc-avJbvyDHY9RvWjGpSAq-o6dS3jQdks5ucrnhgaJpZM4Wwjg4).

[LeifW]

Maybe related to #475?
I was getting a memory leak because apparently things are not freed until you call responseBody on the response (or runResourceT) - and when the responses are just things like 202's or 204's (no content) responseBody is not called. I also talked about it some in the Amazonka gitter channel. My workaround was to just runResourceT on every request.

[neongreen]

My workaround was to just runResourceT on every request.

This is basically what amazonka-1.6.0 is doing, but that's broken in the presence of streaming (connections are being closed too early), see #466

[dsturnbull]

Another workaround is to call deleteMessageBatch even when you are just acking a single message. deleteMessageBatch has a response type, which causes the response body to be evaluated and thus no connection leak.

[neongreen]

Thanks! I'm going to wait for a better fix though, since amazonka is used quite a bit at Wire and I'd rather not depend on nobody accidentally calling "bad" functions. But maybe this workaround will be useful to someone!

…

On Sep 24 2018, at 2:21 am, David Turnbull ***@***.***> wrote: Another workaround is to call deleteMessageBatch even when you are just acking a single message. deleteMessageBatch has a response type, which causes the response body to be evaluated and thus no connection leak. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#490 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABc-anFhNcrMzN5HRY0FwGA99P_rcjTIks5ueCV_gaJpZM4Wwjg4).

[neongreen]

@brendanhay I intend to make a pull-request for this, but I'd love if you (or somebody else) could look at the issue briefly and tell me whether just fixing the receive* family of functions [1] would be enough or you anticipate that more functions would have to be fixed.

[1]

amazonka/core/src/Network/AWS/Response.hs

Lines 41 to 105 in 248f7b2

	receiveNull :: (MonadResource m, MonadThrow m)
	=> Rs a
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveNull rs _ = stream $ \_ _ x ->
	liftResourceT (x `connect` pure (Right rs))
	receiveEmpty :: (MonadResource m, MonadThrow m)
	=> (Int -> ResponseHeaders -> () -> Either String (Rs a))
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveEmpty f _ = stream $ \s h x ->
	liftResourceT (x `connect` pure (f s h ()))
	receiveXMLWrapper :: (MonadResource m, MonadThrow m)
	=> Text
	-> (Int -> ResponseHeaders -> [Node] -> Either String (Rs a))
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveXMLWrapper n f = receiveXML (\s h x -> x .@ n >>= f s h)
	receiveXML :: (MonadResource m, MonadThrow m)
	=> (Int -> ResponseHeaders -> [Node] -> Either String (Rs a))
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveXML = deserialise decodeXML
	receiveJSON :: (MonadResource m, MonadThrow m)
	=> (Int -> ResponseHeaders -> Object -> Either String (Rs a))
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveJSON = deserialise eitherDecode'
	receiveBytes :: (MonadResource m, MonadThrow m)
	=> (Int -> ResponseHeaders -> ByteString -> Either String (Rs a))
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveBytes = deserialise (Right . LBS.toStrict)
	receiveBody :: (MonadResource m, MonadThrow m)
	=> (Int -> ResponseHeaders -> RsBody -> Either String (Rs a))
	-> Logger
	-> Service
	-> Proxy a
	-> ClientResponse
	-> m (Response a)
	receiveBody f _ = stream $ \s h x -> pure (f s h (RsBody x))