NettyAsyncHttpProvider does not persist Payload on PUT request when channel is closed and on a retry

[charlesk40]

Using 1.8.7.

Also, when connection pool is disabled (which we really don't want to disable), this behavior doesn't occur.

#415 seems to address somewhat of an issue for closed channel but there is still an issue where I'm losing the payload for PUT requests resulting in 0-byte files.

17:13:40.647 DEBUG [thread: Jfrog uploader-pool-8-thread-1] c.n.h.c.p.n.NettyAsyncHttpProvider.lookupInCache:430 - Using cached Channel [id: 0xc1cf589e, /10.72.55.56:52506 => test.artifactory.corp.yahoo.com/68.142.238.49:9999]
for uri http://test.artifactory.corp.yahoo.com:9999/artifactory/acceptance-test/folder_allowed/200_mb.rpm;X-uploaded-by=charlesk

------- Here we get closed event.

17:14:05.945 DEBUG [thread: New I/O worker #7] c.n.h.c.p.n.NettyAsyncHttpProvider.channelClosed:1450 - Channel Closed: [id: 0xc1cf589e, /10.72.55.56:52506 :> test.artifactory.corp.yahoo.com/68.142.238.49:9999] with attachment com.ning.http.client.providers.netty.NettyAsyncHttpProvider$DiscardEvent@2015e5de

------- Here is new connection which builds the request again but we already read the inputstream previously. Hence 0-byte.

17:14:49.733 DEBUG [thread: Jfrog uploader-pool-8-thread-1] c.n.h.c.p.n.NettyAsyncHttpProvider.doConnect:1139 -
Non cached request
DefaultHttpRequest(chunked: false)
PUT /artifactory/acceptance-test/folder_allowed/200_mb.rpm;X-uploaded-by=charlesk HTTP/1.1
Host: test.artifactory.corp.yahoo.com:9999
Connection: keep-alive
Accept: /
User-Agent: NING/1.0

------- Note the content -length 0 here
Content-Length: 0

using Channel
[id: 0xf30b823a]

[slandelle]

How did you feed the payload? I would expect this behavior if it was a non resetable stream.

[charlesk40]

I'm using PipedInputStream

[slandelle]

So exactly the type of body that cannot be replayed.

The only InputStreams that can be replay are the ones that support marking (see InputStream.markSupported).

Implementing replay for such InputStream would require buffering the whole stream content just in case the request has to be replayed. Definitively an acceptable overhead.