You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2010/03/01 18:51:05 UTC
[jira] Created: (THRIFT-719) Update Nonblocking and HsHa server to
avoid an extra buffer copy
Update Nonblocking and HsHa server to avoid an extra buffer copy
----------------------------------------------------------------
Key: THRIFT-719
URL: https://issues.apache.org/jira/browse/THRIFT-719
Project: Thrift
Issue Type: Improvement
Affects Versions: 0.3
Reporter: Bryan Duxbury
Assignee: Bryan Duxbury
Fix For: 0.3
Nonblocking and HsHa servers are currently built in such a way that the memory buffer transport that actually contains the whole read message will be wrapped in a new TFramedTransport, which means the first time that you read from this transport, you'll end up copying the whole buffer again.
I'd like to just use a straight TMemoryInputTransport, and stop offering the option of specifying an input transport factory. Doing so is simple, but it has one side effect: you wouldn't be able to customize that transport through use of a Transport Factory. However, I think that it's just too likely someone will screw up either the functionality or the performance of the server by doing so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (THRIFT-719) Update Nonblocking and HsHa server to
avoid an extra buffer copy
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury closed THRIFT-719.
--------------------------------
Resolution: Fixed
With the changes I just committed to the test suite, I know that this doesn't break anything. I just committed this patch.
> Update Nonblocking and HsHa server to avoid an extra buffer copy
> ----------------------------------------------------------------
>
> Key: THRIFT-719
> URL: https://issues.apache.org/jira/browse/THRIFT-719
> Project: Thrift
> Issue Type: Improvement
> Affects Versions: 0.3
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.3
>
> Attachments: thrift-719.patch
>
>
> Nonblocking and HsHa servers are currently built in such a way that the memory buffer transport that actually contains the whole read message will be wrapped in a new TFramedTransport, which means the first time that you read from this transport, you'll end up copying the whole buffer again.
> I'd like to just use a straight TMemoryInputTransport, and stop offering the option of specifying an input transport factory. Doing so is simple, but it has one side effect: you wouldn't be able to customize that transport through use of a Transport Factory. However, I think that it's just too likely someone will screw up either the functionality or the performance of the server by doing so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-719) Update Nonblocking and HsHa server
to avoid an extra buffer copy
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839779#action_12839779 ]
David Reiss commented on THRIFT-719:
------------------------------------
This is how the C++ TNonblockingServer works.
> Update Nonblocking and HsHa server to avoid an extra buffer copy
> ----------------------------------------------------------------
>
> Key: THRIFT-719
> URL: https://issues.apache.org/jira/browse/THRIFT-719
> Project: Thrift
> Issue Type: Improvement
> Affects Versions: 0.3
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.3
>
>
> Nonblocking and HsHa servers are currently built in such a way that the memory buffer transport that actually contains the whole read message will be wrapped in a new TFramedTransport, which means the first time that you read from this transport, you'll end up copying the whole buffer again.
> I'd like to just use a straight TMemoryInputTransport, and stop offering the option of specifying an input transport factory. Doing so is simple, but it has one side effect: you wouldn't be able to customize that transport through use of a Transport Factory. However, I think that it's just too likely someone will screw up either the functionality or the performance of the server by doing so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-719) Update Nonblocking and HsHa server to
avoid an extra buffer copy
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-719:
---------------------------------
Attachment: thrift-719.patch
Here's a patch that I believe makes this change, but I haven't had a chance to whip up a test yet.
> Update Nonblocking and HsHa server to avoid an extra buffer copy
> ----------------------------------------------------------------
>
> Key: THRIFT-719
> URL: https://issues.apache.org/jira/browse/THRIFT-719
> Project: Thrift
> Issue Type: Improvement
> Affects Versions: 0.3
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.3
>
> Attachments: thrift-719.patch
>
>
> Nonblocking and HsHa servers are currently built in such a way that the memory buffer transport that actually contains the whole read message will be wrapped in a new TFramedTransport, which means the first time that you read from this transport, you'll end up copying the whole buffer again.
> I'd like to just use a straight TMemoryInputTransport, and stop offering the option of specifying an input transport factory. Doing so is simple, but it has one side effect: you wouldn't be able to customize that transport through use of a Transport Factory. However, I think that it's just too likely someone will screw up either the functionality or the performance of the server by doing so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.