Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Message-ID: <32136073.1181130746701.JavaMail.jira@brutus>
Date: Wed, 6 Jun 2007 04:52:26 -0700 (PDT)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: httpcomponents-dev@jakarta.apache.org
Subject: [jira] Commented: (HTTPCORE-78) ExpandleBuffer uses direct byte
 buffers
In-Reply-To: <11240558.1181069846476.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCORE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501910 ] 

Oleg Kalnichevski commented on HTTPCORE-78:
-------------------------------------------

Hi Steffen,

> if that is added to the constructor of ExpandableBuffer this will affect a lot of (test) classes it need to be propagated 
> all the way from IOEventDispatch, right?

I believe so. It will not be pretty but we can mitigate the impact on the existing code base by adding an extra constructor that provides some impl of the ByteBufferAllocator per default.

> Are you thinking about something along these lines?

Yes. I do not see a lot of value in providing pooling buffer allocators, hence there is not need to have #release method. This should do

ByteBufferAllocator {
  ByteBuffer allocate(int size);
}

What do you think?

Oleg


> ExpandleBuffer uses direct byte buffers
> ---------------------------------------
>
>                 Key: HTTPCORE-78
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-78
>             Project: HttpComponents Core
>          Issue Type: Improvement
>    Affects Versions: 4.0-alpha4
>            Reporter: Steffen Pingel
>             Fix For: 4.0-alpha5
>
>
> HttpCore allocates subtypes of ExpandleBuffer per connection for buffering requests and responses. ExpandleBuffer creates a buffer using ByteBuffer.allocateDirect() which is initialized to a certain size but may be resized as needed requiring the garbage collector to discard the old buffer. 
> According to the documentation for ByteBuffer, direct buffers are recommended for "large, long-lived buffers that are subject to the underlying system's native I/O operations". It seems that these buffers are rather short-lived and ByteBuffer.allocate() might be a better choice for allocation. 
> Another option would be to pass a factory for allocating and releasing buffers which could reduce the number of allocations by reusing buffers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org