Sébastien Lorber wrote:
> Yes it works nicely :)
>
> Thanks Ryan I think everything is now working for me
You're welcome. Let us know if you run into anything else, or if you
have ideas on improvements, etc.
>
>
> 2013/9/20 Ryan Lubke <ryan.lubke_at_oracle.com
> <mailto:ryan.lubke_at_oracle.com>>
>
> Just following up for closure here. Pool issue has been confirmed
> as resolved.
>
> Sébastien Lorber wrote:
>> Ok thanks :)
>>
>> Take your time
>> We'll keep using no connection pool (as we used to do until now
>> anyway, and we could probably continue with this setting for a
>> while because it passed our load test goals)
>>
>>
>> 2013/9/19 Ryan Lubke <ryan.lubke_at_oracle.com
>> <mailto:ryan.lubke_at_oracle.com>>
>>
>> Sorry, been under the weather. I'll be investigating this
>> issue this morning.
>>
>> Stay tuned.
>>
>> Sébastien Lorber wrote:
>>> So what I've found is that:
>>>
>>>
>>> private final Connection.CloseListener listener = new
>>> Connection.CloseListener() {
>>> @Override
>>> public void onClosed(Connection connection,
>>> Connection.CloseType closeType) throws IOException {
>>> if (closeType ==
>>> Connection.CloseType.REMOTELY) {
>>> if (LOG.isInfoEnabled()) {
>>> LOG.info("Remote closed
>>> connection ({}). Removing from cache", connection.toString());
>>> }
>>> }
>>>
>>> GrizzlyConnectionsPool.this.removeAll(connection);
>>> }
>>> };
>>>
>>>
>>> public boolean removeAll(Connection connection) {
>>>
>>> if (connection == null || closed.get()) {
>>> return false;
>>> }
>>> connection.removeCloseListener(listener);
>>> boolean isRemoved = false;
>>> for (Map.Entry<String,
>>> DelayedExecutor.IdleConnectionQueue> entry :
>>> connectionsPool.entrySet()) {
>>> boolean removed =
>>> entry.getValue().remove(connection);
>>> isRemoved |= removed;
>>> }
>>> return isRemoved;
>>>
>>> }
>>>
>>>
>>>
>>> When the connection is closed remotely, the connection that
>>> we try to remove is never in the cache, thus isRemoved = false
>>>
>>> I guess it has something to do with the "connection
>>> discrimination" you previously fixed and I didn't really
>>> understand :)
>>>
>>> Do you have an idea on this problem?
>>>
>>>
>>>
>>>
>>>
>>> By the way, I just tested again WITHOUT the
>>> FeedableBodyGenerator.
>>> I run batches of 10 concurrent uploads with a max 20
>>> connection pool.
>>> I run these 10 concurrent uploads multiple times.
>>> It works fine, but if just after the request I add a
>>> Thread.sleep(15000) then it seems to lead to the same problem:
>>>
>>> @Test
>>> public void do_test_without_ahc_streaming() throws Exception {
>>> List<Response> responses =
>>> runConcurrently(CONCURRENT_UPLOADS,new Callable<Response>() {
>>> @Override
>>> public Response call() throws Exception {
>>> return uploadSingleDocumentWithoutStreaming();
>>> }
>>> });
>>> runConcurrently(CONCURRENT_UPLOADS,new
>>> Callable<Response>() {
>>> @Override
>>> public Response call() throws Exception {
>>> return uploadSingleDocumentWithoutStreaming();
>>> }
>>> });
>>> Thread.sleep(15000);
>>> runConcurrently(CONCURRENT_UPLOADS,new
>>> Callable<Response>() {
>>> @Override
>>> public Response call() throws Exception {
>>> return uploadSingleDocumentWithoutStreaming();
>>> }
>>> });
>>> Thread.sleep(15000);
>>> runConcurrently(CONCURRENT_UPLOADS,new
>>> Callable<Response>() {
>>> @Override
>>> public Response call() throws Exception {
>>> return uploadSingleDocumentWithoutStreaming();
>>> }
>>> });
>>> Thread.sleep(15000);
>>> runConcurrently(CONCURRENT_UPLOADS,new
>>> Callable<Response>() {
>>> @Override
>>> public Response call() throws Exception {
>>> return uploadSingleDocumentWithoutStreaming();
>>> }
>>> });
>>> Thread.sleep(15000);
>>> ......................................;
>>> }
>>>
>>> This permits to give some time for the remote host to close
>>> the connection
>>>
>>>
>>>
>>> So in the end it seems that we have troubles in any case
>>> when the remote host closes the connection
>>>
>>>
>>>
>>>
>>> Btw I just saw this issue:
>>> https://github.com/AsyncHttpClient/async-http-client/pull/311
>>> I checked the code that used AHC 1.7.7 and what I can see is
>>> that the connection pool is bypassed even with the property=true
>>> I have in my logs:
>>> [main] DEBUG
>>> com.ning.http.client.providers.grizzly.GrizzlyConnectionsPool:162
>>> - [poll] No existing queue for uri
>>> [https://digiposte.orsid.com:443].
>>>
>>>
>>> So, by updating to 1.7.20-SNAPSHOT, the connection pool has
>>> been magically enabled, and it doesn't seem to work well for me.
>>>
>>>
>>> I'll keep that pool disabled because it's the behavior of
>>> our previous applicative version that is near to production
>>> and works pretty fine, but will open a Github issue because
>>> i'm quitting my job next month and they want to track when
>>> they'll be able to use a connection pool :)
>>>
>>>
>>>
>>> 2013/9/19 Sébastien Lorber <lorber.sebastien_at_gmail.com
>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>
>>> So it seems I can reproduce this in local.
>>>
>>> Disabling the ssl connection pooling solve the problem.
>>>
>>>
>>> We didn't have this problems with v1.7.7 we previously used.
>>>
>>> I just tested with the last commits of 1.7.20-SNAPSHOT,
>>> the problem is still here.
>>> The problem doesn't appear on normal AHC requests,
>>> neither on multipart file upload when I do not use the
>>> FeedableBodyGenerator so it seems this is the new
>>> behavior of FeedableBodyGenerator that has a problem
>>> with the ssl connection pooling. Will try to investigate
>>> this.
>>>
>>> By the way, your last commits about selector/worker
>>> threads seems ok (didn't notice any problem with the ssl
>>> pool disabled)
>>>
>>>
>>>
>>> 2013/9/18 Sébastien Lorber <lorber.sebastien_at_gmail.com
>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>
>>> Hi
>>>
>>> Unfortunatly it seems there's another problem.
>>> On our test environment I often get in the logs:
>>>
>>> Caught internal server errorjava.io.IOException:
>>> Maximum pooled connections exceeded
>>> at
>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$AsyncHttpClientEventFilter.cleanup(GrizzlyAsyncHttpProvider.java:1415)
>>> ~[async-http-client-1.7.20-2846817.jar:na]
>>> at
>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$AsyncHttpClientEventFilter.onHttpPacketParsed(GrizzlyAsyncHttpProvider.java:1366)
>>> ~[async-http-client-1.7.20-2846817.jar:na]
>>> at
>>> org.glassfish.grizzly.http.HttpCodecFilter.decodeWithTransferEncoding(HttpCodecFilter.java:1176)
>>> ~[grizzly-http-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.http.HttpCodecFilter.handleRead(HttpCodecFilter.java:516)
>>> ~[grizzly-http-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.http.HttpClientFilter.handleRead(HttpClientFilter.java:161)
>>> ~[grizzly-http-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:546)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> Wrapped by: java.util.concurrent.ExecutionException:
>>> java.io.IOException: Maximum pooled connections exceeded
>>> at
>>> org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:359)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:265)
>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>> at
>>> com.ning.http.client.providers.grizzly.GrizzlyResponseFuture.get(GrizzlyResponseFuture.java:165)
>>> ~[async-http-client-1.7.20-2846817.jar:na]
>>>
>>>
>>>
>>>
>>> boolean canReturnConnection(final Connection
>>> c) {
>>>
>>> return (DO_NOT_CACHE.get(c) != null ||
>>> pool.canCacheConnection());
>>>
>>> }
>>>
>>>
>>> private static HttpTransactionContext
>>> cleanup(final FilterChainContext ctx,
>>>
>>> final GrizzlyAsyncHttpProvider provider) {
>>>
>>> final Connection c = ctx.getConnection();
>>> final HttpTransactionContext context =
>>>
>>> provider.getHttpTransactionContext(c);
>>>
>>> context.provider.setHttpTransactionContext(c, null);
>>> if
>>> (!context.provider.connectionManager.canReturnConnection(c))
>>> {
>>> context.abort(new
>>> IOException("Maximum pooled connections exceeded"));
>>> } else {
>>> if
>>> (!context.provider.connectionManager.returnConnection(context.request,
>>> c)) {
>>> ctx.getConnection().close();
>>> }
>>> }
>>>
>>> return context;
>>>
>>> }
>>>
>>>
>>>
>>> We use:
>>>
>>> Key=[properties.httpclient.allowSslConnectionPool]
>>> Value=[true]
>>> Key=[properties.httpclient.maximumConnectionsPerHost] Value=[20]
>>> Key=[properties.httpclient.maximumConnectionsTotal]
>>> Value=[30]
>>> Key=[properties.httpclient.timeout.connection]
>>> Value=[10000]
>>> Key=[properties.httpclient.timeout.request]
>>> Value=[30000]
>>>
>>>
>>> In our logs, I can see there are 30 times this log:
>>>
>>> Remote closed connection
>>> (TCPNIOConnection{localSocketAddress={/172.16.104.160:55488
>>> <http://172.16.104.160:55488>},
>>> peerSocketAddress={host/172.16.4.100:443}}).
>>> Removing from cache
>>>
>>> and then it seems no connection is never available
>>> and the app is blocked.
>>>
>>> I'll try tomorrow to disable or increase the pool
>>> size, but if you have any idea of the problem please
>>> let me know.
>>> We do not run load tests, these are simple
>>> functional tests with nearly no concurrency.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>> 2013/9/17 Ryan Lubke <ryan.lubke_at_oracle.com
>>> <mailto:ryan.lubke_at_oracle.com>>
>>>
>>> This is good to hear. Thanks for all the
>>> feedback and working with us to nail this down.
>>>
>>>
>>> Sébastien Lorber wrote:
>>>> Thanks,
>>>>
>>>> We already installed the previous snapshot in
>>>> our nexus because it works fine and I'm working
>>>> on something else now but I'll give you a
>>>> feedback soon to see if this still works fine.
>>>> For us it doesn't really mater which thread is
>>>> using since we do not use Future in our
>>>> applications for this case.
>>>>
>>>>
>>>> Btw I've been able deploy a main with my code
>>>> running concurrent uploads on a server which
>>>> has a better connectivity with the remote API
>>>> and it seems I can upload up to 150 concurrent
>>>> files of 10mb with a heap of 250mo in 30
>>>> seconds and a throughput near 50mb/s
>>>>
>>>> I don't really know the infrastructure on which
>>>> my code was deployed but I suspect Grizzly is
>>>> not the bottleneck anymore :)
>>>> When I have more than 150 concurrent uploads
>>>> the remote endpoint seems to timeout under the
>>>> load.
>>>>
>>>>
>>>>
>>>>
>>>> 2013/9/16 Ryan Lubke <ryan.lubke_at_oracle.com
>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>
>>>>
>>>>
>>>> Ryan Lubke wrote:
>>>>>
>>>>>
>>>>> Sébastien Lorber wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> I noticed something strange.
>>>>>> On the FileInputStream I have, I've added
>>>>>> a log on the close() of the stream which
>>>>>> is called once the whole file has been
>>>>>> read to be sent to the feeder.
>>>>>>
>>>>>> 1) If I perform a request (ie my session
>>>>>> init request in the previous discussions)
>>>>>> before doing my multipart upload, the
>>>>>> thread that does execute the feeding is
>>>>>> the thread that fires the request, and
>>>>>> not a Grizzly worker.
>>>>>> [Thread-30] INFO Will close file stream
>>>>>> java.io.FileInputStream_at_27fe4315 after
>>>>>> having read 1440304 bytes
>>>>>>
>>>>>>
>>>>>> 2) If I don't do any request before
>>>>>> firing the multipart upload, the thread
>>>>>> that does the feeding is a Grizzly
>>>>>> threadpool worker thread:
>>>>>> [Grizzly(22)] INFO Will close file stream
>>>>>> java.io.FileInputStream_at_59ac4002 after
>>>>>> having read 1440304 bytes
>>>>>>
>>>>>>
>>>>>> Is this normal? I would expect a worker
>>>>>> thread to always be used, and the main
>>>>>> applicative thread that performs the
>>>>>> request to never be blocking. (but it's
>>>>>> not such an issue for me, we don't have a
>>>>>> reactive non-blocking app anyway)
>>>>> It's currently expected behavior. Will
>>>>> need to re-evaluate this based on the new
>>>>> semantics of the FeedableBodyGenerator.
>>>> I've committed a change for this. If, upon
>>>> testing, you find there is still an issue,
>>>> please let us know.
>>>>
>>>>>>
>>>>>>
>>>>>> On the 1st case, here's the stacktrace
>>>>>> when the feed method is called:
>>>>>>
>>>>>> *at
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.initializeAsynchronousTransfer(FeedableBodyGenerator.java:178)*
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$BodyGeneratorBodyHandler.doHandle(GrizzlyAsyncHttpProvider.java:2210)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider.sendRequest(GrizzlyAsyncHttpProvider.java:564)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$AsyncHttpClientFilter.sendAsGrizzlyRequest(GrizzlyAsyncHttpProvider.java:913)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$AsyncHttpClientFilter.handleWrite(GrizzlyAsyncHttpProvider.java:795)
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>>>>> at
>>>>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.write(DefaultFilterChain.java:437)
>>>>>> at
>>>>>> org.glassfish.grizzly.nio.NIOConnection.write(NIOConnection.java:387)
>>>>>> at
>>>>>> org.glassfish.grizzly.nio.NIOConnection.write(NIOConnection.java:361)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider.execute(GrizzlyAsyncHttpProvider.java:307)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$1.completed(GrizzlyAsyncHttpProvider.java:224)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$1.completed(GrizzlyAsyncHttpProvider.java:210)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$ConnectionManager.doAsyncTrackedConnection(GrizzlyAsyncHttpProvider.java:2289)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider.execute(GrizzlyAsyncHttpProvider.java:244)
>>>>>> *at
>>>>>> com.ning.http.client.AsyncHttpClient.executeRequest(AsyncHttpClient.java:534)*
>>>>>>
>>>>>> So it seems this happen when the
>>>>>> handshake has already been done when
>>>>>> *initializeAsynchronousTransfer* is
>>>>>> called, so that we do not go through
>>>>>> the HandshakeListener
>>>>>>
>>>>>>
>>>>>> Notice that this case seems to also
>>>>>> happen in a few threads on the 2nd case,
>>>>>> but most of the threads are Grizzly workers.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/9/12 Sébastien Lorber
>>>>>> <lorber.sebastien_at_gmail.com
>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>>
>>>>>> Thanks, it seems to work.
>>>>>>
>>>>>> I would suggest to throw IOException
>>>>>> on the flush method since the feed
>>>>>> method is supposed to be called here
>>>>>>
>>>>>>
>>>>>> My implementation of flush is:
>>>>>>
>>>>>> @Override
>>>>>> public void flush() {
>>>>>> Part[] partsArray =
>>>>>> parts.toArray(new Part[parts.size()]);
>>>>>> try ( OutputStream outputStream
>>>>>> = createFeedingOutputStream() ) {
>>>>>>
>>>>>> Part.sendParts(outputStream,partsArray,multipartBoundary);
>>>>>> } catch (Exception e) {
>>>>>> throw new
>>>>>> IllegalStateException("Unable to feed
>>>>>> the FeedableBodyGenerator",e);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Is this correct? The OutputStream
>>>>>> redirects the bytes written to the
>>>>>> feed(Buffer) method
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> There seems to be some concurrency
>>>>>> issue. Because the upload of 1 file
>>>>>> seems fine, but when using multiple
>>>>>> threads, I often get the following stack:
>>>>>> Caused by: java.io.IOException:
>>>>>> Stream Closed
>>>>>> at
>>>>>> java.io.FileInputStream.readBytes(Native
>>>>>> Method)
>>>>>> at
>>>>>> java.io.FileInputStream.read(FileInputStream.java:242)
>>>>>> at
>>>>>> com.google.common.io.CountingInputStream.read(CountingInputStream.java:62)
>>>>>> at
>>>>>> java.io.FilterInputStream.read(FilterInputStream.java:133)
>>>>>> at
>>>>>> java.io.FilterInputStream.read(FilterInputStream.java:107)
>>>>>> at
>>>>>> com.ning.http.multipart.FilePart.sendData(FilePart.java:178)
>>>>>> at
>>>>>> com.ning.http.multipart.Part.send(Part.java:331)
>>>>>> at
>>>>>> com.ning.http.multipart.Part.sendParts(Part.java:397)
>>>>>>
>>>>>>
>>>>>> This is because the flush() method is
>>>>>> called multiple times for the same
>>>>>> request on some cases.
>>>>>> I guess this is not supposed to happen.
>>>>>> What I understand is that the flush()
>>>>>> method is supposed to be called only
>>>>>> once.
>>>>>>
>>>>>>
>>>>>> Using debug logging breakpoints I get
>>>>>> the following:
>>>>>>
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.042 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 0 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.042 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 1 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.043 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 2 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.043 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 3 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.043 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 4 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.044 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 5 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.044 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 6 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.044 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 7 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.045 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 8 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.045 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 9 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.045 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 10 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.046 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 11 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.047 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 12 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.048 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 13 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.049 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 14 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.049 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 15 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.050 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 16 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.050 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 17 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.051 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 18 started
>>>>>> myapp--api-test
>>>>>> 12/09/2013-12:20:46.051 [] [] [main]
>>>>>> INFO
>>>>>> com.myapp.perf.DocumentUploadPerfIntegrationTest:77
>>>>>> - Thread 19 started
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_417de6ff
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_6c0d6ef7
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_7799b411
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_1c940409
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_480f9510
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_3e888183
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_17840db8
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_2cbad94b
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_64c0a4ae
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_102873a6
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_3d5d9ee8
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_51557949
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_6f95de2f
>>>>>> Adding handshake listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_346d784c
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_7799b411
>>>>>> *Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_5befaa07*
>>>>>> *Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_5befaa07*
>>>>>> *Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_5befaa07*
>>>>>> *Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_102873a6*
>>>>>> *Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_102873a6*
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_346d784c
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_64c0a4ae
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_674735a8
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_64c0a4ae
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_480f9510
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_6c0d6ef7
>>>>>> Completing and removing handshake
>>>>>> listener for
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator_at_1daf8fd8
>>>>>>
>>>>>>
>>>>>> As you can see the same
>>>>>> HandshakeListener seems to be called
>>>>>> multiple times for the same
>>>>>> FeedableBodyGenerator
>>>>>>
>>>>>> When this happens, the stack is:
>>>>>>
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator$1.onComplete(FeedableBodyGenerator.java:198)
>>>>>> ~[async-http-client-1.7.20-SNAPSHOT.jar:na]
>>>>>> at
>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.notifyHandshakeComplete(SSLBaseFilter.java:880)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.ssl.SSLFilter.notifyHandshakeComplete(SSLFilter.java:282)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:275)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$SwitchingSSLFilter.handleRead(GrizzlyAsyncHttpProvider.java:2490)
>>>>>> ~[async-http-client-1.7.20-SNAPSHOT.jar:na]
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:546)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>> at
>>>>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> So I tried with the following code:
>>>>>>
>>>>>> private boolean alreadyFlushed = false;
>>>>>> @Override
>>>>>> public synchronized void flush() {
>>>>>> if ( alreadyFlushed ) {
>>>>>> return;
>>>>>> }
>>>>>> startFeeding();
>>>>>> alreadyFlushed = true;
>>>>>> }
>>>>>>
>>>>>> It works fine when upload small files.
>>>>>>
>>>>>> But with larger files, I often get
>>>>>> TimeoutException stacks for some of
>>>>>> the threads:
>>>>>>
>>>>>> Caused by:
>>>>>> java.util.concurrent.TimeoutException
>>>>>> at
>>>>>> org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:367)
>>>>>> at
>>>>>> org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:274)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator$BaseFeeder.block(FeedableBodyGenerator.java:349)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator$BaseFeeder.blockUntilQueueFree(FeedableBodyGenerator.java:339)
>>>>>> at
>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator$BaseFeeder.feed(FeedableBodyGenerator.java:306)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Did I miss something?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/9/12 Ryan Lubke
>>>>>> <ryan.lubke_at_oracle.com
>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>
>>>>>> Committed another small change.
>>>>>> Please make sure you're at the
>>>>>> latest when you build.
>>>>>>
>>>>>> -rl
>>>>>>
>>>>>>
>>>>>> Ryan Lubke wrote:
>>>>>>> Okay, I've committed another set
>>>>>>> of refactorings to the
>>>>>>> FeedableBodyGenerator.
>>>>>>>
>>>>>>> For your use case, you should
>>>>>>> extend
>>>>>>> FeedableBodyGenerator.SimpleFeeder.
>>>>>>>
>>>>>>> Let me know if you run into issues.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sébastien Lorber wrote:
>>>>>>>> Yes I think it would, so that I
>>>>>>>> can feed the queue at once
>>>>>>>>
>>>>>>>> One thread will be locked
>>>>>>>> during the feeding for nothing
>>>>>>>> but it's not a real problem in
>>>>>>>> my usecase.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/9/10 Ryan Lubke
>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>
>>>>>>>> Would having a different
>>>>>>>> listener that will be
>>>>>>>> notified once async
>>>>>>>> transferring has been
>>>>>>>> started work better for you?
>>>>>>>>
>>>>>>>> Something like:
>>>>>>>>
>>>>>>>> onAsyncTransferInitiated() {
>>>>>>>> // invoke your feed method
>>>>>>>> }
>>>>>>>>
>>>>>>>> ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sébastien Lorber wrote:
>>>>>>>>> Unfortunatly I won't be
>>>>>>>>> able to use the Feeder
>>>>>>>>> non-blocking stuff for
>>>>>>>>> now, because of how the
>>>>>>>>> multipart request in
>>>>>>>>> handled in AHC
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here's my feeding method:
>>>>>>>>>
>>>>>>>>> public void feed()
>>>>>>>>> throws IOException {
>>>>>>>>> Part[] partsArray =
>>>>>>>>> parts.toArray(new
>>>>>>>>> Part[parts.size()]);
>>>>>>>>> try ( OutputStream
>>>>>>>>> outputStream =
>>>>>>>>> createFeedingOutputStream() )
>>>>>>>>> {
>>>>>>>>>
>>>>>>>>> Part.sendParts(outputStream,partsArray,multipartBoundary);
>>>>>>>>> } catch (Exception e) {
>>>>>>>>> throw new
>>>>>>>>> IllegalStateException("Unable
>>>>>>>>> to feed the
>>>>>>>>> FeedableBodyGenerator",e);
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As you can see, the
>>>>>>>>> multipart Parts array can
>>>>>>>>> only be pushed to the
>>>>>>>>> OutputStream, I don't have
>>>>>>>>> any way to "pull" the data
>>>>>>>>> when the canFeed() method
>>>>>>>>> is triggered.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But I've seen that there's
>>>>>>>>> a com.ning.http.multipart.MultipartBody#read
>>>>>>>>> that seems to provide a
>>>>>>>>> memory efficient way to
>>>>>>>>> pull data from a Multipart
>>>>>>>>> body...
>>>>>>>>>
>>>>>>>>> Should see what I come up
>>>>>>>>> with this
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/9/10 Sébastien Lorber
>>>>>>>>> <lorber.sebastien_at_gmail.com <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>
>>>>>>>>> It seems the Feeder is
>>>>>>>>> highly recommended but
>>>>>>>>> not mandatory so I
>>>>>>>>> tried without.
>>>>>>>>>
>>>>>>>>> With my existing code
>>>>>>>>> it seems there is a
>>>>>>>>> synchronization problem.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The feeding threads
>>>>>>>>> get locked to
>>>>>>>>> the prematureFeed.get();
>>>>>>>>>
>>>>>>>>> So the Grizzly kernel
>>>>>>>>> threads are unable to
>>>>>>>>> acquire the lock
>>>>>>>>> required to enter
>>>>>>>>> the initializeAsynchronousTransfer
>>>>>>>>> method
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Will try with an
>>>>>>>>> implementation of Feeder
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/9/10 Sébastien
>>>>>>>>> Lorber
>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>
>>>>>>>>> Hmmm it seems I
>>>>>>>>> have a problem
>>>>>>>>> with one of your
>>>>>>>>> maven plugins.
>>>>>>>>> I'll try to bypass
>>>>>>>>> it, but for info:
>>>>>>>>>
>>>>>>>>> ➜ ahc2
>>>>>>>>> git:(ahc-1.7.x)
>>>>>>>>> mvn clean install
>>>>>>>>> [WARNING]
>>>>>>>>> [WARNING] Some
>>>>>>>>> problems were
>>>>>>>>> encountered while
>>>>>>>>> building the
>>>>>>>>> effective settings
>>>>>>>>> [WARNING]
>>>>>>>>> 'profiles.profile[default].repositories.repository.id
>>>>>>>>> <http://repositories.repository.id>'
>>>>>>>>> must be unique but
>>>>>>>>> found duplicate
>>>>>>>>> repository with id
>>>>>>>>> fullsix-maven-repository
>>>>>>>>> @
>>>>>>>>> /home/slorber/.m2/settings.xml
>>>>>>>>> [WARNING]
>>>>>>>>> [INFO] Scanning
>>>>>>>>> for projects...
>>>>>>>>> [INFO]
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO] Building
>>>>>>>>> Asynchronous Http
>>>>>>>>> Client 1.7.20-SNAPSHOT
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO]
>>>>>>>>> [INFO] ---
>>>>>>>>> maven-clean-plugin:2.4.1:clean
>>>>>>>>> (default-clean) @
>>>>>>>>> async-http-client ---
>>>>>>>>> [INFO]
>>>>>>>>> [INFO] ---
>>>>>>>>> maven-enforcer-plugin:1.0-beta-1:enforce
>>>>>>>>> (enforce-maven) @
>>>>>>>>> async-http-client ---
>>>>>>>>> [INFO]
>>>>>>>>> [INFO] ---
>>>>>>>>> maven-enforcer-plugin:1.0-beta-1:enforce
>>>>>>>>> (enforce-versions)
>>>>>>>>> @
>>>>>>>>> async-http-client ---
>>>>>>>>> [INFO]
>>>>>>>>> [INFO] ---
>>>>>>>>> maven-resources-plugin:2.4.3:resources
>>>>>>>>> (default-resources) @
>>>>>>>>> async-http-client ---
>>>>>>>>> [INFO] Using
>>>>>>>>> 'UTF-8' encoding
>>>>>>>>> to copy filtered
>>>>>>>>> resources.
>>>>>>>>> [INFO] skip non
>>>>>>>>> existing
>>>>>>>>> resourceDirectory
>>>>>>>>> /home/slorber/Bureau/ahc2/src/main/resources
>>>>>>>>> [INFO]
>>>>>>>>> [INFO] ---
>>>>>>>>> maven-compiler-plugin:2.3.2:compile
>>>>>>>>> (default-compile)
>>>>>>>>> @
>>>>>>>>> async-http-client ---
>>>>>>>>> [INFO] Compiling
>>>>>>>>> 158 source files
>>>>>>>>> to
>>>>>>>>> /home/slorber/Bureau/ahc2/target/classes
>>>>>>>>> [INFO]
>>>>>>>>> *[INFO] ---
>>>>>>>>> animal-sniffer-maven-plugin:1.6:check
>>>>>>>>> (check-java-1.5-compat)
>>>>>>>>> @
>>>>>>>>> async-http-client ---*
>>>>>>>>> *[INFO] Checking
>>>>>>>>> unresolved
>>>>>>>>> references to
>>>>>>>>> org.codehaus.mojo.signature:java15:1.0*
>>>>>>>>> *[ERROR] Undefined
>>>>>>>>> reference:
>>>>>>>>> java/io/IOException.<init>(Ljava/lang/Throwable;)V
>>>>>>>>> in
>>>>>>>>> /home/slorber/Bureau/ahc2/target/classes/com/ning/http/client/providers/grizzly/FeedableBodyGenerator.class*
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO] BUILD FAILURE
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO] Total time:
>>>>>>>>> 8.747s
>>>>>>>>> [INFO] Finished
>>>>>>>>> at: Tue Sep 10
>>>>>>>>> 11:25:41 CEST 2013
>>>>>>>>> [INFO] Final
>>>>>>>>> Memory: 30M/453M
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> *[ERROR] Failed to
>>>>>>>>> execute goal
>>>>>>>>> org.codehaus.mojo:animal-sniffer-maven-plugin:1.6:check
>>>>>>>>> (check-java-1.5-compat)
>>>>>>>>> on project
>>>>>>>>> async-http-client:
>>>>>>>>> Signature errors
>>>>>>>>> found. Verify them
>>>>>>>>> and put
>>>>>>>>> @IgnoreJRERequirement
>>>>>>>>> on them. -> [Help 1]*
>>>>>>>>> [ERROR]
>>>>>>>>> [ERROR] To see the
>>>>>>>>> full stack trace
>>>>>>>>> of the errors,
>>>>>>>>> re-run Maven with
>>>>>>>>> the -e switch.
>>>>>>>>> [ERROR] Re-run
>>>>>>>>> Maven using the -X
>>>>>>>>> switch to enable
>>>>>>>>> full debug logging.
>>>>>>>>> [ERROR]
>>>>>>>>> [ERROR] For more
>>>>>>>>> information about
>>>>>>>>> the errors and
>>>>>>>>> possible
>>>>>>>>> solutions, please
>>>>>>>>> read the following
>>>>>>>>> articles:
>>>>>>>>> [ERROR] [Help 1]
>>>>>>>>> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/9/10
>>>>>>>>> Sébastien Lorber
>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>
>>>>>>>>> Ok thank you,
>>>>>>>>> I'll try to
>>>>>>>>> implement that
>>>>>>>>> today and will
>>>>>>>>> give you my
>>>>>>>>> feedback :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/9/10 Ryan
>>>>>>>>> Lubke
>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>
>>>>>>>>> Okay,
>>>>>>>>>
>>>>>>>>> I've
>>>>>>>>> committed
>>>>>>>>> my initial
>>>>>>>>> changes to
>>>>>>>>> the AHC
>>>>>>>>> repository.
>>>>>>>>> Here's a
>>>>>>>>> summary of
>>>>>>>>> the changes:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Improvements to the FeedableBodyGenerator (Grizzly's).
>>>>>>>>> - Don't
>>>>>>>>> allow
>>>>>>>>> queueing
>>>>>>>>> of data
>>>>>>>>> before
>>>>>>>>> initiateAsyncTransfer
>>>>>>>>> has been
>>>>>>>>> invoked.
>>>>>>>>> In low memory
>>>>>>>>> heaps,
>>>>>>>>> this could
>>>>>>>>> lead to an
>>>>>>>>> OOM if the
>>>>>>>>> source is
>>>>>>>>> feeding
>>>>>>>>> too fast.
>>>>>>>>> The new
>>>>>>>>> behavior is to
>>>>>>>>> block
>>>>>>>>> until
>>>>>>>>> initiateAsyncTransfer
>>>>>>>>> is called,
>>>>>>>>> at which
>>>>>>>>> time the
>>>>>>>>> blocked
>>>>>>>>> thread may
>>>>>>>>> proceed with
>>>>>>>>> the feed
>>>>>>>>> operation.
>>>>>>>>> -
>>>>>>>>> Introduce
>>>>>>>>> the
>>>>>>>>> concept of
>>>>>>>>> a Feeder.
>>>>>>>>> Implementations
>>>>>>>>> are
>>>>>>>>> responsible,
>>>>>>>>> at a high
>>>>>>>>> level, for:
>>>>>>>>> + letting
>>>>>>>>> the
>>>>>>>>> provider
>>>>>>>>> know that
>>>>>>>>> data is
>>>>>>>>> available
>>>>>>>>> to be fed
>>>>>>>>> without
>>>>>>>>> blocking
>>>>>>>>> + allowing
>>>>>>>>> the
>>>>>>>>> registration
>>>>>>>>> of a
>>>>>>>>> callback
>>>>>>>>> that the
>>>>>>>>> Feeder
>>>>>>>>> implementation
>>>>>>>>> may invoke
>>>>>>>>> to signal
>>>>>>>>> that more
>>>>>>>>> data is
>>>>>>>>> available,
>>>>>>>>> if it
>>>>>>>>> wasn't
>>>>>>>>> available
>>>>>>>>> at a
>>>>>>>>> previous
>>>>>>>>> point in time.
>>>>>>>>> - When
>>>>>>>>> using a
>>>>>>>>> Feeder
>>>>>>>>> with a
>>>>>>>>> secure
>>>>>>>>> request,
>>>>>>>>> the SSL
>>>>>>>>> handshake
>>>>>>>>> will be
>>>>>>>>> kicked off
>>>>>>>>> by the
>>>>>>>>> initiateAsyncTransfer
>>>>>>>>> call, but
>>>>>>>>> feeding of
>>>>>>>>> data will
>>>>>>>>> not occur
>>>>>>>>> until the
>>>>>>>>> handshake
>>>>>>>>> is complete.
>>>>>>>>> This is
>>>>>>>>> necessary
>>>>>>>>> as the
>>>>>>>>> SSLFilter
>>>>>>>>> will queue
>>>>>>>>> up all
>>>>>>>>> writes
>>>>>>>>> until the
>>>>>>>>> handshake
>>>>>>>>> is complete,
>>>>>>>>> and
>>>>>>>>> currently,
>>>>>>>>> the buffer
>>>>>>>>> isn't tied
>>>>>>>>> in with
>>>>>>>>> the
>>>>>>>>> transport
>>>>>>>>> flow
>>>>>>>>> control
>>>>>>>>> mechanism.
>>>>>>>>> NOTE: This
>>>>>>>>> new SSL
>>>>>>>>> behavior
>>>>>>>>> is not
>>>>>>>>> currently
>>>>>>>>> applied
>>>>>>>>> when
>>>>>>>>> invoking
>>>>>>>>> the feed()
>>>>>>>>> method
>>>>>>>>> outside
>>>>>>>>> the
>>>>>>>>> context of
>>>>>>>>> a Feeder.
>>>>>>>>> Still need
>>>>>>>>> to address
>>>>>>>>> that.
>>>>>>>>> - Exposed
>>>>>>>>> configuration
>>>>>>>>> of the
>>>>>>>>> async
>>>>>>>>> write
>>>>>>>>> queue
>>>>>>>>> limit
>>>>>>>>> through
>>>>>>>>> the
>>>>>>>>> FeedableBodyGenerator.
>>>>>>>>> This is an
>>>>>>>>> improvement on
>>>>>>>>> using a
>>>>>>>>> TransportCustomizer
>>>>>>>>> as any
>>>>>>>>> configuration
>>>>>>>>> there is
>>>>>>>>> transport-wide,
>>>>>>>>> and
>>>>>>>>> therefor
>>>>>>>>> applied to
>>>>>>>>> all
>>>>>>>>> Connections.
>>>>>>>>> By
>>>>>>>>> exposing
>>>>>>>>> it here,
>>>>>>>>> each feeder
>>>>>>>>> may have a
>>>>>>>>> different
>>>>>>>>> byte limit.
>>>>>>>>> - Improved
>>>>>>>>> documentation
>>>>>>>>> for this
>>>>>>>>> class*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I
>>>>>>>>> recommend
>>>>>>>>> reading
>>>>>>>>> through
>>>>>>>>> the
>>>>>>>>> javadoc
>>>>>>>>> comments
>>>>>>>>> in the
>>>>>>>>> source [1]
>>>>>>>>> for
>>>>>>>>> FeedableBodyGenerator
>>>>>>>>> (comments
>>>>>>>>> welcome).
>>>>>>>>> Additionally,
>>>>>>>>> I would
>>>>>>>>> re-work
>>>>>>>>> your code
>>>>>>>>> to
>>>>>>>>> leverage
>>>>>>>>> the Feeder
>>>>>>>>> instead of
>>>>>>>>> calling
>>>>>>>>> feed()
>>>>>>>>> directly.
>>>>>>>>>
>>>>>>>>> If you
>>>>>>>>> have
>>>>>>>>> issues
>>>>>>>>> implementing
>>>>>>>>> Feeder, do
>>>>>>>>> let us know.
>>>>>>>>>
>>>>>>>>> If you
>>>>>>>>> have
>>>>>>>>> additional
>>>>>>>>> questions,
>>>>>>>>> again, let
>>>>>>>>> us know.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -rl
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://github.com/AsyncHttpClient/async-http-client/blob/ahc-1.7.x/src/main/java/com/ning/http/client/providers/grizzly/FeedableBodyGenerator.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ryan Lubke
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sébastien
>>>>>>>>>> Lorber
>>>>>>>>>> wrote:
>>>>>>>>>>> So in
>>>>>>>>>>> the end
>>>>>>>>>>> I've end
>>>>>>>>>>> up with
>>>>>>>>>>> an
>>>>>>>>>>> implementation
>>>>>>>>>>> that's
>>>>>>>>>>> working
>>>>>>>>>>> for me.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think
>>>>>>>>>>> there
>>>>>>>>>>> are 2 bugs:
>>>>>>>>>>>
>>>>>>>>>>> 1) The
>>>>>>>>>>> bytes
>>>>>>>>>>> can
>>>>>>>>>>> accumulate
>>>>>>>>>>> in the
>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>> queue if
>>>>>>>>>>> the
>>>>>>>>>>> initialize(ctx)
>>>>>>>>>>> method
>>>>>>>>>>> is not
>>>>>>>>>>> called
>>>>>>>>>>> fast enough.
>>>>>>>>>>> This can
>>>>>>>>>>> be
>>>>>>>>>>> solved
>>>>>>>>>>> by using
>>>>>>>>>>> a
>>>>>>>>>>> BlockingQueue
>>>>>>>>>>> of size
>>>>>>>>>>> 1 and
>>>>>>>>>>> the
>>>>>>>>>>> put()
>>>>>>>>>>> method.
>>>>>>>>>>>
>>>>>>>>>>> 2) Once
>>>>>>>>>>> the
>>>>>>>>>>> context
>>>>>>>>>>> is
>>>>>>>>>>> injected, the
>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>> flushes
>>>>>>>>>>> the queue.
>>>>>>>>>>> The
>>>>>>>>>>> matter
>>>>>>>>>>> is that
>>>>>>>>>>> if the
>>>>>>>>>>> connection
>>>>>>>>>>> is new,
>>>>>>>>>>> not
>>>>>>>>>>> warmed
>>>>>>>>>>> up by a
>>>>>>>>>>> previous
>>>>>>>>>>> request,
>>>>>>>>>>> then the
>>>>>>>>>>> SSL
>>>>>>>>>>> handshake is
>>>>>>>>>>> not done
>>>>>>>>>>> yet, and
>>>>>>>>>>> it seems
>>>>>>>>>>> that the
>>>>>>>>>>> bytes
>>>>>>>>>>> are
>>>>>>>>>>> accumulated
>>>>>>>>>>> in some
>>>>>>>>>>> part of
>>>>>>>>>>> the SSL
>>>>>>>>>>> filter
>>>>>>>>>>> which
>>>>>>>>>>> doesn't
>>>>>>>>>>> deliver
>>>>>>>>>>> them to
>>>>>>>>>>> the
>>>>>>>>>>> connection
>>>>>>>>>>> until
>>>>>>>>>>> the
>>>>>>>>>>> handshake has
>>>>>>>>>>> completed,
>>>>>>>>>>> so c.canWrite()
>>>>>>>>>>> continues to
>>>>>>>>>>> return true.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have
>>>>>>>>>>> replaced
>>>>>>>>>>> some
>>>>>>>>>>> part of
>>>>>>>>>>> the
>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>> to test
>>>>>>>>>>> this and
>>>>>>>>>>> it works
>>>>>>>>>>> pretty
>>>>>>>>>>> fine.
>>>>>>>>>>> See what
>>>>>>>>>>> I have
>>>>>>>>>>> changed:
>>>>>>>>>>>
>>>>>>>>>>> 1)
>>>>>>>>>>>
>>>>>>>>>>> private
>>>>>>>>>>> final
>>>>>>>>>>> BlockingQueue<BodyPart>
>>>>>>>>>>> queue =
>>>>>>>>>>> new
>>>>>>>>>>> LinkedBlockingQueue<BodyPart>(1);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2)
>>>>>>>>>>>
>>>>>>>>>>> public
>>>>>>>>>>> void
>>>>>>>>>>> feed(final
>>>>>>>>>>> Buffer
>>>>>>>>>>> buffer,
>>>>>>>>>>> final
>>>>>>>>>>> boolean
>>>>>>>>>>> last)
>>>>>>>>>>> throws
>>>>>>>>>>> IOException
>>>>>>>>>>> {
>>>>>>>>>>>
>>>>>>>>>>> try {
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> queue.put(new
>>>>>>>>>>> BodyPart(buffer,
>>>>>>>>>>> last));
>>>>>>>>>>>
>>>>>>>>>>> } catch
>>>>>>>>>>> (InterruptedException
>>>>>>>>>>> e) {
>>>>>>>>>>>
>>>>>>>>>>> throw
>>>>>>>>>>> new
>>>>>>>>>>> RuntimeException(e);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> queueSize.incrementAndGet();
>>>>>>>>>>>
>>>>>>>>>>> if
>>>>>>>>>>> (context
>>>>>>>>>>> != null) {
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> blockUntilConnectionIsReadyToWrite(context);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> flushQueue(true);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> private
>>>>>>>>>>> void
>>>>>>>>>>> blockUntilConnectionIsReadyToWrite(FilterChainContext
>>>>>>>>>>> fcc) {
>>>>>>>>>>> if
>>>>>>>>>>> (
>>>>>>>>>>> !connectionIsReadyToWrite(fcc)
>>>>>>>>>>> ) {
>>>>>>>>>>>
>>>>>>>>>>> while (
>>>>>>>>>>> !connectionIsReadyToWrite(fcc)
>>>>>>>>>>> ) {
>>>>>>>>>>>
>>>>>>>>>>> try {
>>>>>>>>>>> Thread.sleep(10);
>>>>>>>>>>> } catch
>>>>>>>>>>> (
>>>>>>>>>>> Exception e
>>>>>>>>>>> ) {
>>>>>>>>>>> throw
>>>>>>>>>>> new
>>>>>>>>>>> RuntimeException(e);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> private
>>>>>>>>>>> boolean
>>>>>>>>>>> connectionIsReadyToWrite(FilterChainContext
>>>>>>>>>>> fcc) {
>>>>>>>>>>>
>>>>>>>>>>> Connection
>>>>>>>>>>> connection
>>>>>>>>>>> =
>>>>>>>>>>> fcc.getConnection();
>>>>>>>>>>>
>>>>>>>>>>> SSLEngine sslEngine
>>>>>>>>>>> =
>>>>>>>>>>> SSLUtils.getSSLEngine(connection);
>>>>>>>>>>>
>>>>>>>>>>> return
>>>>>>>>>>> sslEngine !=
>>>>>>>>>>> null &&
>>>>>>>>>>> !SSLUtils.isHandshaking(sslEngine);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What do
>>>>>>>>>>> you think?
>>>>>>>>>>
>>>>>>>>>> We had
>>>>>>>>>> come to
>>>>>>>>>> similar
>>>>>>>>>> conclusions
>>>>>>>>>> on this
>>>>>>>>>> end. I'm
>>>>>>>>>> still
>>>>>>>>>> working
>>>>>>>>>> through
>>>>>>>>>> testing
>>>>>>>>>> the idea
>>>>>>>>>> I
>>>>>>>>>> mentioned
>>>>>>>>>> previously (took
>>>>>>>>>> longer
>>>>>>>>>> than I
>>>>>>>>>> expected
>>>>>>>>>> - sorry).
>>>>>>>>>> I hope to
>>>>>>>>>> have
>>>>>>>>>> something
>>>>>>>>>> for you
>>>>>>>>>> to test
>>>>>>>>>> very soon.
>>>>>>>>>>
>>>>>>>>>> Note that
>>>>>>>>>> it will
>>>>>>>>>> be taking
>>>>>>>>>> the above
>>>>>>>>>> into
>>>>>>>>>> account
>>>>>>>>>> as well.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/9/5
>>>>>>>>>>> Sébastien Lorber
>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>> have
>>>>>>>>>>> tried to
>>>>>>>>>>> put
>>>>>>>>>>> a
>>>>>>>>>>> while (
>>>>>>>>>>> context
>>>>>>>>>>> ==
>>>>>>>>>>> null
>>>>>>>>>>> )
>>>>>>>>>>> Thread.sleep
>>>>>>>>>>> but
>>>>>>>>>>> it
>>>>>>>>>>> doesn't
>>>>>>>>>>> seem
>>>>>>>>>>> to
>>>>>>>>>>> work, when
>>>>>>>>>>> the
>>>>>>>>>>> context
>>>>>>>>>>> gets
>>>>>>>>>>> injected,
>>>>>>>>>>> after the
>>>>>>>>>>> sleeps,
>>>>>>>>>>> there's
>>>>>>>>>>> an OOM
>>>>>>>>>>>
>>>>>>>>>>> So I
>>>>>>>>>>> hope
>>>>>>>>>>> you'll
>>>>>>>>>>> have
>>>>>>>>>>> more
>>>>>>>>>>> success
>>>>>>>>>>> with
>>>>>>>>>>> your
>>>>>>>>>>> alternative
>>>>>>>>>>> :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>> have
>>>>>>>>>>> done
>>>>>>>>>>> another
>>>>>>>>>>> test, remember
>>>>>>>>>>> my
>>>>>>>>>>> code
>>>>>>>>>>> that
>>>>>>>>>>> worked,
>>>>>>>>>>> which previously
>>>>>>>>>>> "warmed"
>>>>>>>>>>> the
>>>>>>>>>>> Thread
>>>>>>>>>>> with
>>>>>>>>>>> an
>>>>>>>>>>> useless
>>>>>>>>>>> request.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> private
>>>>>>>>>>> Runnable
>>>>>>>>>>> uploadSingleDocumentRunnable
>>>>>>>>>>> =
>>>>>>>>>>> new
>>>>>>>>>>> Runnable()
>>>>>>>>>>> {
>>>>>>>>>>>
>>>>>>>>>>> @Override
>>>>>>>>>>>
>>>>>>>>>>> public
>>>>>>>>>>> void
>>>>>>>>>>> run() {
>>>>>>>>>>>
>>>>>>>>>>> try {
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> getUselessSessionCode();
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thread.sleep(X);
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> uploadSingleDocument();
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>> catch (
>>>>>>>>>>> Exception
>>>>>>>>>>> e ) {
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> throw new
>>>>>>>>>>> RuntimeException("file
>>>>>>>>>>> upload
>>>>>>>>>>> failed",e);
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>> have
>>>>>>>>>>> put
>>>>>>>>>>> a
>>>>>>>>>>> sleep of
>>>>>>>>>>> X
>>>>>>>>>>> between
>>>>>>>>>>> the
>>>>>>>>>>> useless
>>>>>>>>>>> warmup
>>>>>>>>>>> request,
>>>>>>>>>>> and
>>>>>>>>>>> the
>>>>>>>>>>> real
>>>>>>>>>>> upload
>>>>>>>>>>> request
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What
>>>>>>>>>>> I
>>>>>>>>>>> noticed
>>>>>>>>>>> is
>>>>>>>>>>> that
>>>>>>>>>>> there is
>>>>>>>>>>> a
>>>>>>>>>>> very
>>>>>>>>>>> different
>>>>>>>>>>> behavior
>>>>>>>>>>> according
>>>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>> value of
>>>>>>>>>>> X
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Under 10
>>>>>>>>>>> seconds,
>>>>>>>>>>> it
>>>>>>>>>>> seems the
>>>>>>>>>>> stuff is
>>>>>>>>>>> still warm,
>>>>>>>>>>> I
>>>>>>>>>>> can
>>>>>>>>>>> upload
>>>>>>>>>>> the
>>>>>>>>>>> documents.
>>>>>>>>>>> Around
>>>>>>>>>>> 10
>>>>>>>>>>> seconds
>>>>>>>>>>> I
>>>>>>>>>>> get
>>>>>>>>>>> a
>>>>>>>>>>> stack which
>>>>>>>>>>> seems to
>>>>>>>>>>> be
>>>>>>>>>>> "connection
>>>>>>>>>>> closed"
>>>>>>>>>>> or
>>>>>>>>>>> something
>>>>>>>>>>> Above 10
>>>>>>>>>>> seconds,
>>>>>>>>>>> I
>>>>>>>>>>> get
>>>>>>>>>>> OOM
>>>>>>>>>>> like
>>>>>>>>>>> if
>>>>>>>>>>> the
>>>>>>>>>>> stuff wasn't
>>>>>>>>>>> warm.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The
>>>>>>>>>>> stacks
>>>>>>>>>>> I
>>>>>>>>>>> get
>>>>>>>>>>> for
>>>>>>>>>>> 10
>>>>>>>>>>> seconds
>>>>>>>>>>> looks like
>>>>>>>>>>>
>>>>>>>>>>> Caused
>>>>>>>>>>> by:
>>>>>>>>>>> javax.net.ssl.SSLException:
>>>>>>>>>>> SSLEngine
>>>>>>>>>>> is
>>>>>>>>>>> CLOSED
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.wrap(SSLConnectionContext.java:295)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.wrapAll(SSLConnectionContext.java:238)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.wrapAll(SSLBaseFilter.java:405)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.handleWrite(SSLBaseFilter.java:320)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.accurateWrite(SSLFilter.java:255)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.handleWrite(SSLFilter.java:143)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$SwitchingSSLFilter.handleWrite(GrizzlyAsyncHttpProvider.java:2500)
>>>>>>>>>>> ~[async-http-client-1.7.20-SNAPSHOT.jar:na]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:853)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:720)
>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>> at
>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.flushQueue(FeedableBodyGenerator.java:133)
>>>>>>>>>>> ~[async-http-client-1.7.20-SNAPSHOT.jar:na]
>>>>>>>>>>> at
>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.feed(FeedableBodyGenerator.java:95)
>>>>>>>>>>> ~[async-http-client-1.7.20-SNAPSHOT.jar:na]
>>>>>>>>>>>
>>>>>>>>>>> I
>>>>>>>>>>> think I
>>>>>>>>>>> got
>>>>>>>>>>> some
>>>>>>>>>>> other different
>>>>>>>>>>> stacks
>>>>>>>>>>> saying
>>>>>>>>>>> Connection
>>>>>>>>>>> Closed
>>>>>>>>>>> Remotely
>>>>>>>>>>> or
>>>>>>>>>>> something
>>>>>>>>>>> like
>>>>>>>>>>> that.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So
>>>>>>>>>>> it
>>>>>>>>>>> seems that
>>>>>>>>>>> something
>>>>>>>>>>> is
>>>>>>>>>>> bound to
>>>>>>>>>>> my
>>>>>>>>>>> thread,
>>>>>>>>>>> and
>>>>>>>>>>> it
>>>>>>>>>>> stays bound
>>>>>>>>>>> to
>>>>>>>>>>> it
>>>>>>>>>>> for
>>>>>>>>>>> about 10
>>>>>>>>>>> seconds,
>>>>>>>>>>> do
>>>>>>>>>>> you
>>>>>>>>>>> have
>>>>>>>>>>> any
>>>>>>>>>>> idea
>>>>>>>>>>> what
>>>>>>>>>>> it
>>>>>>>>>>> could be?
>>>>>>>>>>> (My
>>>>>>>>>>> connection
>>>>>>>>>>> timeout
>>>>>>>>>>> setting
>>>>>>>>>>> seems to
>>>>>>>>>>> have
>>>>>>>>>>> no
>>>>>>>>>>> effect
>>>>>>>>>>> on
>>>>>>>>>>> this
>>>>>>>>>>> 10s
>>>>>>>>>>> threshold)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/9/5
>>>>>>>>>>> Ryan
>>>>>>>>>>> Lubke <ryan.lubke_at_oracle.com
>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>
>>>>>>>>>>> That
>>>>>>>>>>> is
>>>>>>>>>>> one
>>>>>>>>>>> solution.
>>>>>>>>>>> I'm
>>>>>>>>>>> working
>>>>>>>>>>> out
>>>>>>>>>>> an
>>>>>>>>>>> alternative
>>>>>>>>>>> right
>>>>>>>>>>> now.
>>>>>>>>>>> Stay
>>>>>>>>>>> tuned!
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Anyway
>>>>>>>>>>>> it's
>>>>>>>>>>>> not
>>>>>>>>>>>> a
>>>>>>>>>>>> problem,
>>>>>>>>>>>> I
>>>>>>>>>>>> think
>>>>>>>>>>>> the
>>>>>>>>>>>> FeedableBodyGenerator.feed()
>>>>>>>>>>>> method
>>>>>>>>>>>> just
>>>>>>>>>>>> has
>>>>>>>>>>>> to
>>>>>>>>>>>> block
>>>>>>>>>>>> until
>>>>>>>>>>>> a
>>>>>>>>>>>> context
>>>>>>>>>>>> has
>>>>>>>>>>>> been
>>>>>>>>>>>> (and
>>>>>>>>>>>> ThreadCache
>>>>>>>>>>>> initialized)
>>>>>>>>>>>> to
>>>>>>>>>>>> avoid
>>>>>>>>>>>> OOM
>>>>>>>>>>>> errors
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2013/9/5
>>>>>>>>>>>> Sébastien
>>>>>>>>>>>> Lorber
>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What
>>>>>>>>>>>> is
>>>>>>>>>>>> very
>>>>>>>>>>>> strange
>>>>>>>>>>>> is
>>>>>>>>>>>> that
>>>>>>>>>>>> I tested
>>>>>>>>>>>> with/without
>>>>>>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>> sessionCode
>>>>>>>>>>>> with
>>>>>>>>>>>> our
>>>>>>>>>>>> previous
>>>>>>>>>>>> code,
>>>>>>>>>>>> the
>>>>>>>>>>>> one
>>>>>>>>>>>> not
>>>>>>>>>>>> using
>>>>>>>>>>>> FeedableBodyGenerator,
>>>>>>>>>>>> which
>>>>>>>>>>>> has
>>>>>>>>>>>> a high
>>>>>>>>>>>> memory
>>>>>>>>>>>> consumption.
>>>>>>>>>>>> Despites
>>>>>>>>>>>> the
>>>>>>>>>>>> fact
>>>>>>>>>>>> it
>>>>>>>>>>>> had
>>>>>>>>>>>> high
>>>>>>>>>>>> memory
>>>>>>>>>>>> consumption,
>>>>>>>>>>>> it
>>>>>>>>>>>> seems
>>>>>>>>>>>> work
>>>>>>>>>>>> fine
>>>>>>>>>>>> to
>>>>>>>>>>>> upload
>>>>>>>>>>>> multiple
>>>>>>>>>>>> documents
>>>>>>>>>>>> if
>>>>>>>>>>>> allocated
>>>>>>>>>>>> with
>>>>>>>>>>>> a large
>>>>>>>>>>>> heap,
>>>>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>> sessionCode
>>>>>>>>>>>> seems
>>>>>>>>>>>> to
>>>>>>>>>>>> have
>>>>>>>>>>>> no
>>>>>>>>>>>> effect.
>>>>>>>>>>>>
>>>>>>>>>>>> On
>>>>>>>>>>>> the
>>>>>>>>>>>> new
>>>>>>>>>>>> impl
>>>>>>>>>>>> using
>>>>>>>>>>>> the
>>>>>>>>>>>> FeedableBodyGenerator,
>>>>>>>>>>>> the
>>>>>>>>>>>> sessionCode
>>>>>>>>>>>> sent
>>>>>>>>>>>> as
>>>>>>>>>>>> a multipart
>>>>>>>>>>>> bodypart
>>>>>>>>>>>> seems
>>>>>>>>>>>> to
>>>>>>>>>>>> have
>>>>>>>>>>>> an
>>>>>>>>>>>> effect.
>>>>>>>>>>>>
>>>>>>>>>>>> I have
>>>>>>>>>>>> tried
>>>>>>>>>>>> to
>>>>>>>>>>>> feed
>>>>>>>>>>>> the
>>>>>>>>>>>> queue
>>>>>>>>>>>> before
>>>>>>>>>>>> sending
>>>>>>>>>>>> the
>>>>>>>>>>>> request
>>>>>>>>>>>> to
>>>>>>>>>>>> AHC,
>>>>>>>>>>>> but
>>>>>>>>>>>> this
>>>>>>>>>>>> leads
>>>>>>>>>>>> to
>>>>>>>>>>>> this
>>>>>>>>>>>> exception
>>>>>>>>>>>> (with/without
>>>>>>>>>>>> sessionCode
>>>>>>>>>>>> switching)
>>>>>>>>>>>> Caused
>>>>>>>>>>>> by:
>>>>>>>>>>>> java.util.concurrent.TimeoutException:
>>>>>>>>>>>> Timeout
>>>>>>>>>>>> exceeded
>>>>>>>>>>>> at
>>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider.timeout(GrizzlyAsyncHttpProvider.java:528)
>>>>>>>>>>>> at
>>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$3.onTimeout(GrizzlyAsyncHttpProvider.java:361)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.glassfish.grizzly.utils.IdleTimeoutFilter$DefaultWorker.doWork(IdleTimeoutFilter.java:383)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.glassfish.grizzly.utils.IdleTimeoutFilter$DefaultWorker.doWork(IdleTimeoutFilter.java:362)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.glassfish.grizzly.utils.DelayedExecutor$DelayedRunnable.run(DelayedExecutor.java:158)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2013/9/5
>>>>>>>>>>>> Sébastien
>>>>>>>>>>>> Lorber
>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>
>>>>>>>>>>>> By
>>>>>>>>>>>> the
>>>>>>>>>>>> way,
>>>>>>>>>>>> by
>>>>>>>>>>>> using
>>>>>>>>>>>> a low
>>>>>>>>>>>> timeout
>>>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>> sessioncode,
>>>>>>>>>>>> I got
>>>>>>>>>>>> the
>>>>>>>>>>>> following
>>>>>>>>>>>> NPE:
>>>>>>>>>>>>
>>>>>>>>>>>> Caused
>>>>>>>>>>>> by:
>>>>>>>>>>>> java.lang.NullPointerException
>>>>>>>>>>>> at
>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.block(FeedableBodyGenerator.java:184)
>>>>>>>>>>>> at
>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.blockUntilQueueFree(FeedableBodyGenerator.java:167)
>>>>>>>>>>>> at
>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.flushQueue(FeedableBodyGenerator.java:124)
>>>>>>>>>>>> at
>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.feed(FeedableBodyGenerator.java:94)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> GrizzlyAsyncHttpProvider.HttpTransactionContext
>>>>>>>>>>>> httpCtx
>>>>>>>>>>>> =
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> getHttpTransactionContext(c);
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> httpCtx.abort(e.getCause());
>>>>>>>>>>>>
>>>>>>>>>>>> I guess
>>>>>>>>>>>> the
>>>>>>>>>>>> httpCtx
>>>>>>>>>>>> is
>>>>>>>>>>>> not
>>>>>>>>>>>> already
>>>>>>>>>>>> available
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> aborted
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2013/9/5
>>>>>>>>>>>> Sébastien
>>>>>>>>>>>> Lorber
>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This
>>>>>>>>>>>> is
>>>>>>>>>>>> right,
>>>>>>>>>>>> here's
>>>>>>>>>>>> a log
>>>>>>>>>>>> I have
>>>>>>>>>>>> when
>>>>>>>>>>>> I use
>>>>>>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>> session
>>>>>>>>>>>> code,
>>>>>>>>>>>> ie
>>>>>>>>>>>> the
>>>>>>>>>>>> remote
>>>>>>>>>>>> host
>>>>>>>>>>>> is
>>>>>>>>>>>> blocking
>>>>>>>>>>>> the
>>>>>>>>>>>> data
>>>>>>>>>>>> or
>>>>>>>>>>>> something.
>>>>>>>>>>>> This
>>>>>>>>>>>> is
>>>>>>>>>>>> obtained
>>>>>>>>>>>> by
>>>>>>>>>>>> running
>>>>>>>>>>>> 5 parallel
>>>>>>>>>>>> uploads.
>>>>>>>>>>>>
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 0 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 97
>>>>>>>>>>>> with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 100
>>>>>>>>>>>> with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 160
>>>>>>>>>>>> with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true*
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 0 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> java.lang.OutOfMemoryError:
>>>>>>>>>>>> GC
>>>>>>>>>>>> overhead
>>>>>>>>>>>> limit
>>>>>>>>>>>> exceeded
>>>>>>>>>>>> Dumping
>>>>>>>>>>>> heap
>>>>>>>>>>>> to
>>>>>>>>>>>> /ome/lorber/ureau/om
>>>>>>>>>>>> ...
>>>>>>>>>>>> Unable
>>>>>>>>>>>> to
>>>>>>>>>>>> create
>>>>>>>>>>>> /ome/lorber/ureau/om:
>>>>>>>>>>>> Le
>>>>>>>>>>>> fichier
>>>>>>>>>>>> existe
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Disconnected
>>>>>>>>>>>> from
>>>>>>>>>>>> the
>>>>>>>>>>>> target
>>>>>>>>>>>> VM,
>>>>>>>>>>>> address:
>>>>>>>>>>>> '127.0.0.1:49268
>>>>>>>>>>>> <http://127.0.0.1:49268>',
>>>>>>>>>>>> transport:
>>>>>>>>>>>> 'socket'
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise,
>>>>>>>>>>>> with
>>>>>>>>>>>> different
>>>>>>>>>>>> session
>>>>>>>>>>>> codes,
>>>>>>>>>>>> I get
>>>>>>>>>>>> the
>>>>>>>>>>>> following:
>>>>>>>>>>>>
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 0 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 0 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 0 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> *Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 0 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = false*
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> Flushing
>>>>>>>>>>>> queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1 with
>>>>>>>>>>>> allowBlocking
>>>>>>>>>>>> = true
>>>>>>>>>>>> ...
>>>>>>>>>>>> and
>>>>>>>>>>>> this
>>>>>>>>>>>> continues
>>>>>>>>>>>> without
>>>>>>>>>>>> OOM
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So,
>>>>>>>>>>>> this
>>>>>>>>>>>> seems
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> the
>>>>>>>>>>>> problem.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think
>>>>>>>>>>>> it
>>>>>>>>>>>> would
>>>>>>>>>>>> be
>>>>>>>>>>>> great
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> able
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> able
>>>>>>>>>>>> to
>>>>>>>>>>>> choose
>>>>>>>>>>>> the
>>>>>>>>>>>> queue
>>>>>>>>>>>> impl
>>>>>>>>>>>> behind
>>>>>>>>>>>> that FeedableBodyGenerator,
>>>>>>>>>>>> like
>>>>>>>>>>>> I suggested
>>>>>>>>>>>> in
>>>>>>>>>>>> my
>>>>>>>>>>>> pull
>>>>>>>>>>>> request.
>>>>>>>>>>>>
>>>>>>>>>>>> See
>>>>>>>>>>>> here:
>>>>>>>>>>>> https://github.com/slorber/async-http-client/blob/79b0c3b28a61b0aa4c4b055bca8f6be11d9ed1e6/src/main/java/com/ning/http/client/providers/grizzly/FeedableBodyGenerator.java
>>>>>>>>>>>>
>>>>>>>>>>>> Using
>>>>>>>>>>>> a LinkedBlockingQueue
>>>>>>>>>>>> seems
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> a nice
>>>>>>>>>>>> idea
>>>>>>>>>>>> in
>>>>>>>>>>>> this
>>>>>>>>>>>> context,
>>>>>>>>>>>> and
>>>>>>>>>>>> in
>>>>>>>>>>>> my
>>>>>>>>>>>> case
>>>>>>>>>>>> I would
>>>>>>>>>>>> probably
>>>>>>>>>>>> use
>>>>>>>>>>>> a queue
>>>>>>>>>>>> of
>>>>>>>>>>>> size
>>>>>>>>>>>> 1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This
>>>>>>>>>>>> would
>>>>>>>>>>>> handle
>>>>>>>>>>>> the
>>>>>>>>>>>> blocking
>>>>>>>>>>>> of
>>>>>>>>>>>> the
>>>>>>>>>>>> feed
>>>>>>>>>>>> method,
>>>>>>>>>>>> without
>>>>>>>>>>>> having
>>>>>>>>>>>> to
>>>>>>>>>>>> use
>>>>>>>>>>>> this:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> if
>>>>>>>>>>>> (context
>>>>>>>>>>>> !=
>>>>>>>>>>>> null)
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> flushQueue(true);
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Or
>>>>>>>>>>>> perhaps
>>>>>>>>>>>> the
>>>>>>>>>>>> feed()
>>>>>>>>>>>> method
>>>>>>>>>>>> have
>>>>>>>>>>>> to
>>>>>>>>>>>> wait
>>>>>>>>>>>> until
>>>>>>>>>>>> a context
>>>>>>>>>>>> is
>>>>>>>>>>>> set
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> BodyGenerator
>>>>>>>>>>>> ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think
>>>>>>>>>>>> it
>>>>>>>>>>>> would
>>>>>>>>>>>> be
>>>>>>>>>>>> more
>>>>>>>>>>>> clear
>>>>>>>>>>>> if
>>>>>>>>>>>> the initializeAsynchronousTransfer
>>>>>>>>>>>> simply
>>>>>>>>>>>> didn't
>>>>>>>>>>>> flush
>>>>>>>>>>>> the
>>>>>>>>>>>> queue
>>>>>>>>>>>> but
>>>>>>>>>>>> just
>>>>>>>>>>>> setup
>>>>>>>>>>>> the
>>>>>>>>>>>> context.
>>>>>>>>>>>> Then
>>>>>>>>>>>> the
>>>>>>>>>>>> feed
>>>>>>>>>>>> method
>>>>>>>>>>>> would
>>>>>>>>>>>> block
>>>>>>>>>>>> until
>>>>>>>>>>>> there's
>>>>>>>>>>>> a context
>>>>>>>>>>>> set,
>>>>>>>>>>>> and
>>>>>>>>>>>> then
>>>>>>>>>>>> flush
>>>>>>>>>>>> the
>>>>>>>>>>>> queue
>>>>>>>>>>>> with
>>>>>>>>>>>> blocking
>>>>>>>>>>>> behavior.
>>>>>>>>>>>>
>>>>>>>>>>>> This
>>>>>>>>>>>> is
>>>>>>>>>>>> probably
>>>>>>>>>>>> the
>>>>>>>>>>>> next
>>>>>>>>>>>> step,
>>>>>>>>>>>> but
>>>>>>>>>>>> as
>>>>>>>>>>>> we
>>>>>>>>>>>> are
>>>>>>>>>>>> using
>>>>>>>>>>>> AHC
>>>>>>>>>>>> for
>>>>>>>>>>>> async,
>>>>>>>>>>>> it
>>>>>>>>>>>> would
>>>>>>>>>>>> probably
>>>>>>>>>>>> be
>>>>>>>>>>>> great
>>>>>>>>>>>> if
>>>>>>>>>>>> that
>>>>>>>>>>>> blocking
>>>>>>>>>>>> feed()
>>>>>>>>>>>> method
>>>>>>>>>>>> was
>>>>>>>>>>>> called
>>>>>>>>>>>> in
>>>>>>>>>>>> a worker
>>>>>>>>>>>> thread
>>>>>>>>>>>> instead
>>>>>>>>>>>> of
>>>>>>>>>>>> our
>>>>>>>>>>>> main
>>>>>>>>>>>> thread.
>>>>>>>>>>>>
>>>>>>>>>>>> I won't
>>>>>>>>>>>> use
>>>>>>>>>>>> this
>>>>>>>>>>>> but
>>>>>>>>>>>> someone
>>>>>>>>>>>> who
>>>>>>>>>>>> really
>>>>>>>>>>>> wants
>>>>>>>>>>>> a non-blocking
>>>>>>>>>>>> impl
>>>>>>>>>>>> of
>>>>>>>>>>>> performant
>>>>>>>>>>>> multipart
>>>>>>>>>>>> fileupload
>>>>>>>>>>>> would
>>>>>>>>>>>> probably
>>>>>>>>>>>> need
>>>>>>>>>>>> this,
>>>>>>>>>>>> or
>>>>>>>>>>>> will
>>>>>>>>>>>> use
>>>>>>>>>>>> an
>>>>>>>>>>>> ExecutorService
>>>>>>>>>>>> for
>>>>>>>>>>>> the
>>>>>>>>>>>> feeding
>>>>>>>>>>>> operations
>>>>>>>>>>>> as
>>>>>>>>>>>> a workaround.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> again
>>>>>>>>>>>> for
>>>>>>>>>>>> your
>>>>>>>>>>>> reactivity
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2013/9/4
>>>>>>>>>>>> Ryan
>>>>>>>>>>>> Lubke
>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sébastien
>>>>>>>>>>>> Lorber
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've
>>>>>>>>>>>>> integrated
>>>>>>>>>>>>> this
>>>>>>>>>>>>> change
>>>>>>>>>>>>> and
>>>>>>>>>>>>> it
>>>>>>>>>>>>> works
>>>>>>>>>>>>> fine
>>>>>>>>>>>>> except
>>>>>>>>>>>>> a little
>>>>>>>>>>>>> detail.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm
>>>>>>>>>>>>> uploading
>>>>>>>>>>>>> files
>>>>>>>>>>>>> to
>>>>>>>>>>>>> a third
>>>>>>>>>>>>> party
>>>>>>>>>>>>> API
>>>>>>>>>>>>> (a
>>>>>>>>>>>>> bit
>>>>>>>>>>>>> like
>>>>>>>>>>>>> S3).
>>>>>>>>>>>>> This
>>>>>>>>>>>>> API
>>>>>>>>>>>>> requires
>>>>>>>>>>>>> a "sessionCode"
>>>>>>>>>>>>> in
>>>>>>>>>>>>> each
>>>>>>>>>>>>> request.
>>>>>>>>>>>>> So
>>>>>>>>>>>>> there
>>>>>>>>>>>>> is
>>>>>>>>>>>>> a multipart
>>>>>>>>>>>>> StringPart
>>>>>>>>>>>>> with
>>>>>>>>>>>>> that
>>>>>>>>>>>>> SessionCode.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We
>>>>>>>>>>>>> used
>>>>>>>>>>>>> to
>>>>>>>>>>>>> have
>>>>>>>>>>>>> a cache
>>>>>>>>>>>>> which
>>>>>>>>>>>>> holds
>>>>>>>>>>>>> the
>>>>>>>>>>>>> sessionCode
>>>>>>>>>>>>> 30min
>>>>>>>>>>>>> per
>>>>>>>>>>>>> user
>>>>>>>>>>>>> so
>>>>>>>>>>>>> that
>>>>>>>>>>>>> we
>>>>>>>>>>>>> do
>>>>>>>>>>>>> not
>>>>>>>>>>>>> need
>>>>>>>>>>>>> to
>>>>>>>>>>>>> init
>>>>>>>>>>>>> a new
>>>>>>>>>>>>> session
>>>>>>>>>>>>> each
>>>>>>>>>>>>> time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had
>>>>>>>>>>>>> troubles
>>>>>>>>>>>>> in
>>>>>>>>>>>>> this
>>>>>>>>>>>>> very
>>>>>>>>>>>>> specific
>>>>>>>>>>>>> case:
>>>>>>>>>>>>> when
>>>>>>>>>>>>> I upload
>>>>>>>>>>>>> 5 docs
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> session
>>>>>>>>>>>>> code.
>>>>>>>>>>>>> When
>>>>>>>>>>>>> I remove
>>>>>>>>>>>>> the
>>>>>>>>>>>>> cache
>>>>>>>>>>>>> and
>>>>>>>>>>>>> use
>>>>>>>>>>>>> 5 different
>>>>>>>>>>>>> session
>>>>>>>>>>>>> codes,
>>>>>>>>>>>>> it
>>>>>>>>>>>>> works
>>>>>>>>>>>>> fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess
>>>>>>>>>>>>> the
>>>>>>>>>>>>> remote
>>>>>>>>>>>>> service
>>>>>>>>>>>>> is
>>>>>>>>>>>>> blocking
>>>>>>>>>>>>> concurrent
>>>>>>>>>>>>> uploads
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> session
>>>>>>>>>>>>> code.
>>>>>>>>>>>>> I don't
>>>>>>>>>>>>> know
>>>>>>>>>>>>> at
>>>>>>>>>>>>> all.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where
>>>>>>>>>>>>> I want
>>>>>>>>>>>>> to
>>>>>>>>>>>>> go
>>>>>>>>>>>>> is
>>>>>>>>>>>>> that
>>>>>>>>>>>>> I wouldn't
>>>>>>>>>>>>> have
>>>>>>>>>>>>> expected
>>>>>>>>>>>>> Grizzly
>>>>>>>>>>>>> to
>>>>>>>>>>>>> OOM
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Avertissement:
>>>>>>>>>>>>> Exception
>>>>>>>>>>>>> during
>>>>>>>>>>>>> FilterChain
>>>>>>>>>>>>> execution
>>>>>>>>>>>>> java.lang.OutOfMemoryError:
>>>>>>>>>>>>> Java
>>>>>>>>>>>>> heap
>>>>>>>>>>>>> space
>>>>>>>>>>>>> at
>>>>>>>>>>>>> java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> java.nio.ByteBuffer.allocate(ByteBuffer.java:331)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLUtils.allocateOutputBuffer(SSLUtils.java:342)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter$2.grow(SSLBaseFilter.java:117)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.ensureBufferSize(SSLConnectionContext.java:392)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.wrap(SSLConnectionContext.java:272)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.wrapAll(SSLConnectionContext.java:238)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.wrapAll(SSLBaseFilter.java:405)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.handleWrite(SSLBaseFilter.java:320)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.accurateWrite(SSLFilter.java:263)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.handleWrite(SSLFilter.java:143)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$SwitchingSSLFilter.handleWrite(GrizzlyAsyncHttpProvider.java:2500)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.FilterChainContext$1.run(FilterChainContext.java:196)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.FilterChainContext.resume(FilterChainContext.java:220)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter$SSLHandshakeContext.completed(SSLFilter.java:383)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.notifyHandshakeComplete(SSLFilter.java:278)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:275)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$SwitchingSSLFilter.handleRead(GrizzlyAsyncHttpProvider.java:2490)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:546)
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Caused
>>>>>>>>>>>>> by:
>>>>>>>>>>>>> java.util.concurrent.TimeoutException:
>>>>>>>>>>>>> null
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:367)
>>>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>>>> at
>>>>>>>>>>>>> org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:274)
>>>>>>>>>>>>> ~[grizzly-framework-2.3.5.jar:2.3.5]
>>>>>>>>>>>>> at
>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.block(FeedableBodyGenerator.java:177)
>>>>>>>>>>>>> ~[async-http-client-1.7.20-204092c.jar:na]
>>>>>>>>>>>>> at
>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.blockUntilQueueFree(FeedableBodyGenerator.java:167)
>>>>>>>>>>>>> ~[async-http-client-1.7.20-204092c.jar:na]
>>>>>>>>>>>>> at
>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.flushQueue(FeedableBodyGenerator.java:124)
>>>>>>>>>>>>> ~[async-http-client-1.7.20-204092c.jar:na]
>>>>>>>>>>>>> at
>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.feed(FeedableBodyGenerator.java:94)
>>>>>>>>>>>>> ~[async-http-client-1.7.20-204092c.jar:na]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> multipart.body.generator.feeder.buffer=100000
>>>>>>>>>>>>> ->
>>>>>>>>>>>>> size
>>>>>>>>>>>>> of
>>>>>>>>>>>>> each
>>>>>>>>>>>>> Buffer
>>>>>>>>>>>>> sent
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>>>> transport.max.pending.bytes=1000000
>>>>>>>>>>>>> (I
>>>>>>>>>>>>> tried
>>>>>>>>>>>>> other
>>>>>>>>>>>>> settings,
>>>>>>>>>>>>> including
>>>>>>>>>>>>> AUTO_SIZE)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do
>>>>>>>>>>>>> you
>>>>>>>>>>>>> have
>>>>>>>>>>>>> any
>>>>>>>>>>>>> idea
>>>>>>>>>>>>> why
>>>>>>>>>>>>> is
>>>>>>>>>>>>> there
>>>>>>>>>>>>> an
>>>>>>>>>>>>> OOM
>>>>>>>>>>>>> with
>>>>>>>>>>>>> these
>>>>>>>>>>>>> settings?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps
>>>>>>>>>>>>> it
>>>>>>>>>>>>> is
>>>>>>>>>>>>> because
>>>>>>>>>>>>> the
>>>>>>>>>>>>> feed()
>>>>>>>>>>>>> method
>>>>>>>>>>>>> of
>>>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>> block
>>>>>>>>>>>>> until
>>>>>>>>>>>>> the
>>>>>>>>>>>>> context
>>>>>>>>>>>>> is
>>>>>>>>>>>>> initialized.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess
>>>>>>>>>>>>> the initializeAsynchronousTransfer
>>>>>>>>>>>>> is
>>>>>>>>>>>>> called
>>>>>>>>>>>>> only
>>>>>>>>>>>>> once
>>>>>>>>>>>>> the
>>>>>>>>>>>>> connection
>>>>>>>>>>>>> is
>>>>>>>>>>>>> established,
>>>>>>>>>>>>> and
>>>>>>>>>>>>> perhaps
>>>>>>>>>>>>> a lot
>>>>>>>>>>>>> of
>>>>>>>>>>>>> Buffer
>>>>>>>>>>>>> are
>>>>>>>>>>>>> added
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> queue...
>>>>>>>>>>>> Yes,
>>>>>>>>>>>> it's
>>>>>>>>>>>> invoked
>>>>>>>>>>>> once
>>>>>>>>>>>> the
>>>>>>>>>>>> request
>>>>>>>>>>>> has
>>>>>>>>>>>> been
>>>>>>>>>>>> dispatched,
>>>>>>>>>>>> so
>>>>>>>>>>>> if
>>>>>>>>>>>> the
>>>>>>>>>>>> generator
>>>>>>>>>>>> is
>>>>>>>>>>>> fed
>>>>>>>>>>>> a lot
>>>>>>>>>>>> before
>>>>>>>>>>>> the
>>>>>>>>>>>> request,
>>>>>>>>>>>> I could
>>>>>>>>>>>> see
>>>>>>>>>>>> this
>>>>>>>>>>>> happening.
>>>>>>>>>>>> I'll
>>>>>>>>>>>> see
>>>>>>>>>>>> what
>>>>>>>>>>>> I can
>>>>>>>>>>>> do
>>>>>>>>>>>> to
>>>>>>>>>>>> alleviate
>>>>>>>>>>>> that
>>>>>>>>>>>> case.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> But
>>>>>>>>>>>>> I'm
>>>>>>>>>>>>> not
>>>>>>>>>>>>> sure
>>>>>>>>>>>>> at
>>>>>>>>>>>>> all
>>>>>>>>>>>>> because
>>>>>>>>>>>>> the
>>>>>>>>>>>>> session
>>>>>>>>>>>>> code
>>>>>>>>>>>>> is
>>>>>>>>>>>>> transmitted
>>>>>>>>>>>>> as
>>>>>>>>>>>>> a BodyPart
>>>>>>>>>>>>> and
>>>>>>>>>>>>> I get
>>>>>>>>>>>>> the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> problem
>>>>>>>>>>>>> if
>>>>>>>>>>>>> i put
>>>>>>>>>>>>> it
>>>>>>>>>>>>> as
>>>>>>>>>>>>> the
>>>>>>>>>>>>> first
>>>>>>>>>>>>> or
>>>>>>>>>>>>> last
>>>>>>>>>>>>> multipart.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's
>>>>>>>>>>>>> not
>>>>>>>>>>>>> a big
>>>>>>>>>>>>> deal,
>>>>>>>>>>>>> perhaps
>>>>>>>>>>>>> I should
>>>>>>>>>>>>> always
>>>>>>>>>>>>> use
>>>>>>>>>>>>> a different
>>>>>>>>>>>>> session
>>>>>>>>>>>>> code
>>>>>>>>>>>>> for
>>>>>>>>>>>>> concurrent
>>>>>>>>>>>>> operations
>>>>>>>>>>>>> but
>>>>>>>>>>>>> I'd
>>>>>>>>>>>>> like
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be
>>>>>>>>>>>>> sure
>>>>>>>>>>>>> that
>>>>>>>>>>>>> we
>>>>>>>>>>>>> won't
>>>>>>>>>>>>> have
>>>>>>>>>>>>> this
>>>>>>>>>>>>> issue
>>>>>>>>>>>>> in
>>>>>>>>>>>>> production...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2013/9/3
>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Good
>>>>>>>>>>>>> catch.
>>>>>>>>>>>>> Fixed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There's
>>>>>>>>>>>>>> a little
>>>>>>>>>>>>>> mistake
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> grizzly
>>>>>>>>>>>>>> ahc
>>>>>>>>>>>>>> provider
>>>>>>>>>>>>>> relative
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> write
>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>> size.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/AsyncHttpClient/async-http-client/blob/b5d97efe9fe14113ea92fb1f7db192a2d090fad7/src/main/java/com/ning/http/client/providers/grizzly/GrizzlyAsyncHttpProvider.java#L419
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> see,
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> TransportCustomizer
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> called,
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> write
>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>> size
>>>>>>>>>>>>>> (among
>>>>>>>>>>>>>> other
>>>>>>>>>>>>>> things)
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> set
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> AUTO_SIZE
>>>>>>>>>>>>>> (instead
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>> UNLIMITED)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> clientTransport.getAsyncQueueIO().getWriter()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> .setMaxPendingBytesPerConnection(AsyncQueueWriter.AUTO_SIZE);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> default
>>>>>>>>>>>>>> settings
>>>>>>>>>>>>>> like
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> AUTO_SIZE
>>>>>>>>>>>>>> attribute
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> set
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> customization
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> transport,
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> they
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> override
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> value
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>> customized.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>> my
>>>>>>>>>>>>>> case,
>>>>>>>>>>>>>> since
>>>>>>>>>>>>>> I can't
>>>>>>>>>>>>>> reproduce
>>>>>>>>>>>>>> my
>>>>>>>>>>>>>> "bug"
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> "high
>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>> consumption",
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>> / UNLIMITED
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> TransportCustomizer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>> work
>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> me
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> AUTO_SIZE,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> I'd
>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> able
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> tune
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> parameter
>>>>>>>>>>>>>> during
>>>>>>>>>>>>>> load
>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> see
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> effect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2013/8/31
>>>>>>>>>>>>>> Sebastien
>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> i will
>>>>>>>>>>>>>> ckeck
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> monday.
>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>> now
>>>>>>>>>>>>>> upload
>>>>>>>>>>>>>> a 500m
>>>>>>>>>>>>>> file
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> 40m
>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>> size
>>>>>>>>>>>>>> ;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Envoyé
>>>>>>>>>>>>>> de
>>>>>>>>>>>>>> mon
>>>>>>>>>>>>>> iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le
>>>>>>>>>>>>>> 30
>>>>>>>>>>>>>> août
>>>>>>>>>>>>>> 2013
>>>>>>>>>>>>>> à 20:49,
>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> updating
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> Grizzly
>>>>>>>>>>>>>>> provider
>>>>>>>>>>>>>>> such
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> AUTO_SIZE
>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>> AUTO_TUNE)
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> default,
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> avoid
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> TransportCustomizer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding
>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>> tuning
>>>>>>>>>>>>>>>> question,
>>>>>>>>>>>>>>>> I would
>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> AsyncQueueWriter.AUTO_TUNE
>>>>>>>>>>>>>>>> (this
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> four
>>>>>>>>>>>>>>>> times
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> socket
>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>> buffer)
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> works.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A question
>>>>>>>>>>>>>>>>> first.
>>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>> changes,
>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>> usage
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> inline
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>> looking
>>>>>>>>>>>>>>>>> for?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> By
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> way,
>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>> idea
>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> 1.7.20
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> released
>>>>>>>>>>>>>>>>>> (with
>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> improvements?)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> wait
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> a release
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> install
>>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>>>>> temp
>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> Nexus
>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2013/8/30
>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thank
>>>>>>>>>>>>>>>>>> you,
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>> fine!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I just
>>>>>>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> modify
>>>>>>>>>>>>>>>>>> a single
>>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>> after
>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>> commit.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider#initializeTransport
>>>>>>>>>>>>>>>>>> ->
>>>>>>>>>>>>>>>>>> clientTransport.getAsyncQueueIO().getWriter().setMaxPendingBytesPerConnection(10000);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>> I let
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> initial
>>>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>>>> (-1)
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> won't
>>>>>>>>>>>>>>>>>> block,
>>>>>>>>>>>>>>>>>> canWrite
>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>> true
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Btw,
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>> I didn't
>>>>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> pass
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>> a config
>>>>>>>>>>>>>>>>>> attribute,
>>>>>>>>>>>>>>>>>> neither
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> talked
>>>>>>>>>>>>>>>>>> about.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> end,
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> "canWrite
>>>>>>>>>>>>>>>>>> = false"
>>>>>>>>>>>>>>>>>> behavior?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>> not,
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> behavior
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> v1.7.20
>>>>>>>>>>>>>>>>>> ? thanks
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> PS:
>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> sens
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> bytes
>>>>>>>>>>>>>>>>>> un
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> feed(Buffer)
>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> setMaxPendingBytesPerConnection(10000);
>>>>>>>>>>>>>>>>>> ? do
>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>> tuning
>>>>>>>>>>>>>>>>>> recommandation?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2013/8/29
>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>>>> disregard.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sébastien,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Could
>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>>>>> a sample
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>>>>> performing
>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>> feed?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> -rl
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sébastien,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'd
>>>>>>>>>>>>>>>>>>>> recommend
>>>>>>>>>>>>>>>>>>>> looking
>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>> Connection.canWrite()
>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> Connection.notifyCanWrite(WriteListener)
>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> By
>>>>>>>>>>>>>>>>>>>> default,
>>>>>>>>>>>>>>>>>>>> Grizzly
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> async
>>>>>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>> length
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> four
>>>>>>>>>>>>>>>>>>>> times
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>> (which
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>>>>>>> off
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> socket
>>>>>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>>>>>> buffer).
>>>>>>>>>>>>>>>>>>>> When
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>> exceeds
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> value,
>>>>>>>>>>>>>>>>>>>> canWrite()
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>>>>>> false.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> occurs,
>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> register
>>>>>>>>>>>>>>>>>>>> a WriteListener
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> notified
>>>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>> length
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> below
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> configured
>>>>>>>>>>>>>>>>>>>> max
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>> simulate
>>>>>>>>>>>>>>>>>>>> blocking
>>>>>>>>>>>>>>>>>>>> until
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> onWritePossible()
>>>>>>>>>>>>>>>>>>>> callback
>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>> invoked.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>>>>>> FutureImpl<Boolean>
>>>>>>>>>>>>>>>>>>>> future
>>>>>>>>>>>>>>>>>>>> = Futures.createSafeFuture();
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> //
>>>>>>>>>>>>>>>>>>>> Connection
>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> obtained
>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>> FilterChainContext.getConnection().
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> connection.notifyCanWrite(new
>>>>>>>>>>>>>>>>>>>> WriteHandler()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>> void
>>>>>>>>>>>>>>>>>>>> onWritePossible()
>>>>>>>>>>>>>>>>>>>> throws
>>>>>>>>>>>>>>>>>>>> Exception
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> future.result(Boolean.TRUE);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>> void
>>>>>>>>>>>>>>>>>>>> onError(Throwable
>>>>>>>>>>>>>>>>>>>> t)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> future.failure(Exceptions.makeIOException(t));
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> });
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>>>> writeTimeout
>>>>>>>>>>>>>>>>>>>> = 30;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> future.get(writeTimeout,
>>>>>>>>>>>>>>>>>>>> TimeUnit.MILLISECONDS);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> } catch
>>>>>>>>>>>>>>>>>>>> (ExecutionException
>>>>>>>>>>>>>>>>>>>> e)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> HttpTransactionContext
>>>>>>>>>>>>>>>>>>>> httpCtx
>>>>>>>>>>>>>>>>>>>> = HttpTransactionContext.get(connection);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> httpCtx.abort(e.getCause());
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> } catch
>>>>>>>>>>>>>>>>>>>> (Exception
>>>>>>>>>>>>>>>>>>>> e)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> HttpTransactionContext
>>>>>>>>>>>>>>>>>>>> httpCtx
>>>>>>>>>>>>>>>>>>>> = HttpTransactionContext.get(connection);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> httpCtx.abort(e);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>> http://grizzly.java.net/docs/2.3/apidocs/org/glassfish/grizzly/OutputSink.html.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ryan,
>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>> did
>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>>>> a blocking
>>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> totally
>>>>>>>>>>>>>>>>>>>>> useless
>>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>> consuming
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>> blocking
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>>>>>>> blocks
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> feeding,
>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>> intention
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> beginning.
>>>>>>>>>>>>>>>>>>>>> Maybe
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> depends
>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> IO
>>>>>>>>>>>>>>>>>>>>> strategy
>>>>>>>>>>>>>>>>>>>>> used?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I use
>>>>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>>>>> default
>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> use SameThreadIOStrategy
>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>> I don't
>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> IO
>>>>>>>>>>>>>>>>>>>>> strategy.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> end
>>>>>>>>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>>>>>>>>> upload
>>>>>>>>>>>>>>>>>>>>> a 70m
>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> a heap
>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> 50m,
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> I have
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>> a Thread.sleep(30)
>>>>>>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>>> 100k
>>>>>>>>>>>>>>>>>>>>> Buffer
>>>>>>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>> connection
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>> good
>>>>>>>>>>>>>>>>>>>>> here,
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> production
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> normally
>>>>>>>>>>>>>>>>>>>>> a lot
>>>>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> I know.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>> tried
>>>>>>>>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>> like clientTransport.getAsyncQueueIO().getWriter().setMaxPendingBytesPerConnection(100000);
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'd
>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> Grizzly
>>>>>>>>>>>>>>>>>>>>> internals
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>> pending
>>>>>>>>>>>>>>>>>>>>> bytes
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> send.
>>>>>>>>>>>>>>>>>>>>> Is
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> possible?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> PS:
>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>> able
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>>>>>> a 500mo
>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> 100mo
>>>>>>>>>>>>>>>>>>>>> heap,
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>>>>>>>> a sleep
>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> 100ms
>>>>>>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>>> 100k
>>>>>>>>>>>>>>>>>>>>> Buffer
>>>>>>>>>>>>>>>>>>>>> sent
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> bodygenerator
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2013/8/29
>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> By
>>>>>>>>>>>>>>>>>>>>> chance
>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>>>>>>>>> remove
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> MessageCloner
>>>>>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> SSL
>>>>>>>>>>>>>>>>>>>>> filter?
>>>>>>>>>>>>>>>>>>>>> SSLBaseFilter$OnWriteCopyCloner
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> allocate
>>>>>>>>>>>>>>>>>>>>> a lot
>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>>>>> I don't
>>>>>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>>> why
>>>>>>>>>>>>>>>>>>>>> messages
>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> cloned,
>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>> I remove
>>>>>>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>>>>>>> How?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2013/8/29
>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>> <lorber.sebastien_at_gmail.com
>>>>>>>>>>>>>>>>>>>>> <mailto:lorber.sebastien_at_gmail.com>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>> trying
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>>>>>> a 500m
>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> a heap
>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> 400m.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>>>> real
>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>>>>>> under
>>>>>>>>>>>>>>>>>>>>> 20mo
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> reduce
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>>>>>> consumption
>>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>> x parallel
>>>>>>>>>>>>>>>>>>>>> uploads
>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>>>> according
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>> activity.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> BodyGenerator
>>>>>>>>>>>>>>>>>>>>> reduced
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>>>>>> footprint
>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>> almost
>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2013/8/28
>>>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> time,
>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> SSL
>>>>>>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>>>>>>> allocation
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> concerned,
>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>> untunable.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That
>>>>>>>>>>>>>>>>>>>>> said,
>>>>>>>>>>>>>>>>>>>>> feel
>>>>>>>>>>>>>>>>>>>>> free
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> open
>>>>>>>>>>>>>>>>>>>>> a feature
>>>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>> second
>>>>>>>>>>>>>>>>>>>>> question,
>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>>>>>>> suggested
>>>>>>>>>>>>>>>>>>>>> size.
>>>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>>> application
>>>>>>>>>>>>>>>>>>>>> specific.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>> curious,
>>>>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>>>>> large
>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> a file
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>> sending?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I have
>>>>>>>>>>>>>>>>>>>>>> seen
>>>>>>>>>>>>>>>>>>>>>> a lot
>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>> buffers
>>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>> a size
>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>> 33842
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> limit
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> near
>>>>>>>>>>>>>>>>>>>>>> half
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> capacity.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Perhaps
>>>>>>>>>>>>>>>>>>>>>> there's
>>>>>>>>>>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> tune
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> consumes
>>>>>>>>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>>>>>>>>> memory?
>>>>>>>>>>>>>>>>>>>>>> Is
>>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>> ideal
>>>>>>>>>>>>>>>>>>>>>> Buffer
>>>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> feed
>>>>>>>>>>>>>>>>>>>>>> method?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2013/8/28
>>>>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> reviewing
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> PR
>>>>>>>>>>>>>>>>>>>>>> today,
>>>>>>>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>>>>>>>>> again!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regarding
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> OOM:
>>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> stands
>>>>>>>>>>>>>>>>>>>>>> now,
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> passed
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> SSLFilter,
>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>> allocate
>>>>>>>>>>>>>>>>>>>>>> a buffer
>>>>>>>>>>>>>>>>>>>>>> twice
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> accommodate
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> encrypted
>>>>>>>>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>>>> there's
>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>> increase.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Depending
>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> socket
>>>>>>>>>>>>>>>>>>>>>> configurations
>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>>>>>>> endpoints,
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>>>>>> fast
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> remote
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> reading
>>>>>>>>>>>>>>>>>>>>>> data,
>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> becoming
>>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>> large.
>>>>>>>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> detect
>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>> situation,
>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> Grizzly
>>>>>>>>>>>>>>>>>>>>>> internals
>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>> shielded
>>>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>> I will
>>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>>>>>>> users
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> leverage
>>>>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>>>> pull
>>>>>>>>>>>>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/AsyncHttpClient/async-http-client/pull/367
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>>>> usecase
>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>> works,
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> uploaded
>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But
>>>>>>>>>>>>>>>>>>>>>>> I didn't
>>>>>>>>>>>>>>>>>>>>>>> notice
>>>>>>>>>>>>>>>>>>>>>>> a big
>>>>>>>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>>>>>>>> improvement.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Is
>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> SSL
>>>>>>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> stream
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> body
>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>> that?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>>>>>>>> I have
>>>>>>>>>>>>>>>>>>>>>>> a lot
>>>>>>>>>>>>>>>>>>>>>>> of:
>>>>>>>>>>>>>>>>>>>>>>> - HeapByteBuffer
>>>>>>>>>>>>>>>>>>>>>>> Which
>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> hold
>>>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>> SSLUtils$3
>>>>>>>>>>>>>>>>>>>>>>> Which
>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> hold
>>>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>> BufferBuffers
>>>>>>>>>>>>>>>>>>>>>>> Which
>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> hold
>>>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>> WriteResult
>>>>>>>>>>>>>>>>>>>>>>> Which
>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>> hold
>>>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>> AsyncWriteQueueRecord
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Here
>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> exemple
>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> OOM
>>>>>>>>>>>>>>>>>>>>>>> stacktrace:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> java.lang.OutOfMemoryError:
>>>>>>>>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> java.nio.ByteBuffer.allocate(ByteBuffer.java:331)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLUtils.allocateOutputBuffer(SSLUtils.java:342)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter$2.grow(SSLBaseFilter.java:117)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.ensureBufferSize(SSLConnectionContext.java:392)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.wrap(SSLConnectionContext.java:272)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLConnectionContext.wrapAll(SSLConnectionContext.java:227)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.wrapAll(SSLBaseFilter.java:404)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLBaseFilter.handleWrite(SSLBaseFilter.java:319)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.accurateWrite(SSLFilter.java:255)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ssl.SSLFilter.handleWrite(SSLFilter.java:143)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$SwitchingSSLFilter.handleWrite(GrizzlyAsyncHttpProvider.java:2503)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:853)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:720)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.flushQueue(FeedableBodyGenerator.java:132)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.FeedableBodyGenerator.feed(FeedableBodyGenerator.java:101)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.MultipartBodyGeneratorFeeder$FeedBodyGeneratorOutputStream.write(MultipartBodyGeneratorFeeder.java:222)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.multipart.FilePart.sendData(FilePart.java:179)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.multipart.Part.send(Part.java:331)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.multipart.Part.sendParts(Part.java:397)
>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>> com.ning.http.client.providers.grizzly.MultipartBodyGeneratorFeeder.feed(MultipartBodyGeneratorFeeder.java:144)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Any
>>>>>>>>>>>>>>>>>>>>>>> idea?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2013/8/27
>>>>>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Excellent!
>>>>>>>>>>>>>>>>>>>>>>> Looking
>>>>>>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> pull
>>>>>>>>>>>>>>>>>>>>>>> request!
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>>>>>>>> fine,
>>>>>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>> a pull
>>>>>>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>>>>>>>> tomorrow
>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>> a better
>>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>>>>>>> Part
>>>>>>>>>>>>>>>>>>>>>>>> classes
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>>>>>>>> exist.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I created
>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>> OutputStream
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> redirects
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> BodyGenerator
>>>>>>>>>>>>>>>>>>>>>>>> feeder.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>>>>>>>>>> I currently
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> feeder
>>>>>>>>>>>>>>>>>>>>>>>> feeds
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>>>>>> faster
>>>>>>>>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> async
>>>>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>>> polling
>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>>>>>>> I need
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> expose
>>>>>>>>>>>>>>>>>>>>>>>> a limit
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>> something,
>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> that,
>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>>>>>> a thread
>>>>>>>>>>>>>>>>>>>>>>>> sleep
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> slow
>>>>>>>>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> filepart
>>>>>>>>>>>>>>>>>>>>>>>> reading
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2013/8/27
>>>>>>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Yes,
>>>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>> I was
>>>>>>>>>>>>>>>>>>>>>>>> going
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> tackle
>>>>>>>>>>>>>>>>>>>>>>>> adding
>>>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>> today.
>>>>>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>>>>>>>>>> up
>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>> test
>>>>>>>>>>>>>>>>>>>>>>>> out.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>> thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I think
>>>>>>>>>>>>>>>>>>>>>>>>> I see
>>>>>>>>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>>>>>>>> I could
>>>>>>>>>>>>>>>>>>>>>>>>> do,
>>>>>>>>>>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>>>> that:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> FeedableBodyGenerator
>>>>>>>>>>>>>>>>>>>>>>>>> bodyGenerator
>>>>>>>>>>>>>>>>>>>>>>>>> = new
>>>>>>>>>>>>>>>>>>>>>>>>> FeedableBodyGenerator();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> MultipartBodyGeneratorFeeder
>>>>>>>>>>>>>>>>>>>>>>>>> bodyGeneratorFeeder
>>>>>>>>>>>>>>>>>>>>>>>>> = new
>>>>>>>>>>>>>>>>>>>>>>>>> MultipartBodyGeneratorFeeder(bodyGenerator);
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Request
>>>>>>>>>>>>>>>>>>>>>>>>> uploadRequest1
>>>>>>>>>>>>>>>>>>>>>>>>> = new
>>>>>>>>>>>>>>>>>>>>>>>>> RequestBuilder("POST")
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> .setUrl("url")
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> .setBody(bodyGenerator)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> .build();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ListenableFuture<Response>
>>>>>>>>>>>>>>>>>>>>>>>>> asyncRes
>>>>>>>>>>>>>>>>>>>>>>>>> = asyncHttpClient
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> .prepareRequest(uploadRequest1)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> .execute(new
>>>>>>>>>>>>>>>>>>>>>>>>> AsyncCompletionHandlerBase());
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bodyGeneratorFeeder.append("param1","value1");
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bodyGeneratorFeeder.append("param2","value2");
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bodyGeneratorFeeder.append("fileToUpload",fileInputStream);
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bodyGeneratorFeeder.end();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Response
>>>>>>>>>>>>>>>>>>>>>>>>> uploadResponse
>>>>>>>>>>>>>>>>>>>>>>>>> = asyncRes.get();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Does
>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>>>>>>>>>>>>> ok
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> you?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I guess
>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>> interesting
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> MultipartBodyGeneratorFeeder
>>>>>>>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>> Grizzly
>>>>>>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> achieve
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2013/8/26
>>>>>>>>>>>>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>>>>>>>>>>>> Lubke
>>>>>>>>>>>>>>>>>>>>>>>>> <ryan.lubke_at_oracle.com
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:ryan.lubke_at_oracle.com>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Sébastien
>>>>>>>>>>>>>>>>>>>>>>>>> Lorber
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I would
>>>>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> upload
>>>>>>>>>>>>>>>>>>>>>>>>> a file
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>>>>>>>>> / Grizzly
>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> streaming,
>>>>>>>>>>>>>>>>>>>>>>>>> I mean
>>>>>>>>>>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> whole
>>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>>> bytes
>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>>>>>> default
>>>>>>>>>>>>>>>>>>>>>>>>> behavior
>>>>>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> allocate
>>>>>>>>>>>>>>>>>>>>>>>>> a byte[]
>>>>>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>>>> contans
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> whole
>>>>>>>>>>>>>>>>>>>>>>>>> file,
>>>>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>> OOM
>>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>>>>>>>>>> users
>>>>>>>>>>>>>>>>>>>>>>>>> upload
>>>>>>>>>>>>>>>>>>>>>>>>> a large
>>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>>>>>>>> time.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>>>>>> tryied
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> a Heap
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> ByteBuffer
>>>>>>>>>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>>>>>>>>>> managers,
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> reallocate=true/false
>>>>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>>>>> success.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> whole
>>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>>> content
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> appended
>>>>>>>>>>>>>>>>>>>>>>>>> wto
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> BufferOutputStream,
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> underlying
>>>>>>>>>>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> written.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>>>>>>>>> least
>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>>>>>>>>> integration:
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/AsyncHttpClient/async-http-client/blob/6faf1f316e5546110b0779a5a42fd9d03ba6bc15/providers/grizzly/src/main/java/org/asynchttpclient/providers/grizzly/bodyhandler/PartsBodyHandler.java
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So,
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>>>>>> a way
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>>>>>>>>> AHC
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> stream
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> I could
>>>>>>>>>>>>>>>>>>>>>>>>> eventually
>>>>>>>>>>>>>>>>>>>>>>>>> consume
>>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>>> 20mo
>>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>>>>>>>>>>> uploading
>>>>>>>>>>>>>>>>>>>>>>>>> a 500mo
>>>>>>>>>>>>>>>>>>>>>>>>> file?
>>>>>>>>>>>>>>>>>>>>>>>>> Or
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>>>>>>>>>>> impossible
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> Grizzly?
>>>>>>>>>>>>>>>>>>>>>>>>> I didn't
>>>>>>>>>>>>>>>>>>>>>>>>> notice
>>>>>>>>>>>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> documentation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It's
>>>>>>>>>>>>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> FeedableBodyGenerator.
>>>>>>>>>>>>>>>>>>>>>>>>> But
>>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>>>>>>>>>>>>> tied
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>>>>>>>> Multipart
>>>>>>>>>>>>>>>>>>>>>>>>> uploads,
>>>>>>>>>>>>>>>>>>>>>>>>> you'd
>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> multipart
>>>>>>>>>>>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> Buffers
>>>>>>>>>>>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> send
>>>>>>>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> FeedableBodyGenerator.
>>>>>>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>>>>>>> a closer
>>>>>>>>>>>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> area
>>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>> improved.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Btw
>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> a file
>>>>>>>>>>>>>>>>>>>>>>>>> upload.
>>>>>>>>>>>>>>>>>>>>>>>>> I receive
>>>>>>>>>>>>>>>>>>>>>>>>> a file
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> transmit
>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> a storage
>>>>>>>>>>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>>>>>>>>>>> (like
>>>>>>>>>>>>>>>>>>>>>>>>> S3).
>>>>>>>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>>>>>>> consume
>>>>>>>>>>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>>>>>>>>>>> bevause
>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> streaming
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> large
>>>>>>>>>>>>>>>>>>>>>>>>> fle
>>>>>>>>>>>>>>>>>>>>>>>>> uploads
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>>> system,
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>>>>>>> provides
>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>> input
>>>>>>>>>>>>>>>>>>>>>>>>> stream
>>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> file.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>
>