Sébastien,
AHC 1.7.20 has been released. It's up on the oss.sonatype.org maven
repository and will be sync'd with central soon-ish.
-rl
Ryan Lubke wrote:
>
>
> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>