hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-78) ExpandleBuffer uses direct byte buffers
Date Wed, 06 Jun 2007 11:52:26 GMT

    [ 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


Mime
View raw message