[
https://issues.apache.org/jira/browse/DIRMINA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Heath resolved DIRMINA-218.
--------------------------------
Resolution: Fixed
Assignee: Trustin Lee (was: Mike Heath)
I made the changes per your suggestion and have committed those changes. I
used the name SendFileRegion for the class that indicates a file is being sent.
Trustin, please review these changes and close the issue when everything looks
satisfactory.
I like this approach a lot better than the initial way I was doing it. I was
also thinking that for use with SSL or compression (or any other filter that
mutates a ByteBuffer), we should create a filter that will convert a
SendFileRegion to a ByteBuffer by reading data from the fileChannel. We would
have to derive some mechanism to avoid OOM exceptions when dealing with large
files.
> Ability to transfer channels to socket channels owned by Mina
> -------------------------------------------------------------
>
> Key: DIRMINA-218
> URL: https://issues.apache.org/jira/browse/DIRMINA-218
> Project: MINA
> Issue Type: New Feature
> Affects Versions: 2.0.0-M1
> Reporter: dave irving
> Assignee: Trustin Lee
> Priority: Minor
> Fix For: 2.0.0-M1
>
> Attachments: sendfile.patch
>
>
> Id like to be able to transfer file contents to a socket as effeciently as
> possible.
> In some cases, making use of FileChannel#transferTo(long, long,
> WritableByteChannel) is a good choice, as it (in theory) allows the OS to do
> the transfer without bringing the file content in to user space (e.g. could
> make use of sendfile behind the scenes or whatever).
> There is no direct way to obtain the channel from an IOSession - but even if
> there was - allowing a user to do this directly is dangerous as Mina could
> have queued writes pending for the channel.
> This JIRA issue can hopefully kick off some discussion.
> I see two basic ways to do this:
> 1) Add "sendFile(FileChannel)" or similar to IoSession. Mina then queues this
> request along with other pending writes. Of course, mina must take care of
> potentially several invocations to FileChannel#transferTo - as all bytes
> might not be transfered in one go.
> 2) Allow the user to schedule their own channel commands. For example, a
> "write command" scheduled by the user would be invoked by mina when the write
> queue was free.
> Im not sure that option 2 is really needed - and could be quite complex, so
> my preference is (1).
> If we can get agreement on approach, I'll start on a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.