[
https://issues.apache.org/jira/browse/HTTPCORE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490185
]
Steffen Pingel commented on HTTPCORE-43:
----------------------------------------
I have similar requirements performance requirements and would like to avoid
buffering in NHttpServiceHandler but write directly to the channel (at least
when LengthDelimitedEncoder is used). I am suggesting a new interface for
entities that are tailored for NIO (so far I have only implemented this for
writing):
public interface HttpNIOEntity extends HttpEntity {
void produceContent(ContentEncoder encoder) throws IOException;
}
My custom service handler invokes entity.produceContent() in outputReady() in
case of HttpNIOEntity objects and uses buffering for other entities. This also
opens the possibility for IO control in entities. I am asynchronously reading
chunks of a file to avoid blocking the NIO thread and use the content encoder
to suspend output if reading from disk is slower than the writing network:
public interface ContentEncoder extends IOControl {
...
}
> Implement support for FileChannel#transferFrom and FileChannel#transferTo
> -------------------------------------------------------------------------
>
> Key: HTTPCORE-43
> URL: https://issues.apache.org/jira/browse/HTTPCORE-43
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Reporter: Oleg Kalnichevski
> Fix For: 4.0-alpha5
>
>
> Implement optional support for FileChannel#transferFrom and
> FileChannel#transferTo operations. Direct coping from and to FileChannel is
> believed to result in a significant performance improvement for file bound
> operations
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
