[
https://issues.apache.org/jira/browse/THRIFT-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221023#comment-16221023
]
ASF GitHub Bot commented on THRIFT-4372:
----------------------------------------
Github user Jens-G commented on the issue:
https://github.com/apache/thrift/pull/1402
> Why not actually use (2^16)-1 which is the limit?
Several reasons. First, aligned memory access is always faster. If we
subtract 1 byte, we get the worst case. Next, at least on Windows a number of
system resources use multiples of 4096, so it is probably not a bad idea to
follow that model. That's why I picked this particular value.
> Pipe write operations across a network are limited to 65,535 bytes per write.
> ------------------------------------------------------------------------------
>
> Key: THRIFT-4372
> URL: https://issues.apache.org/jira/browse/THRIFT-4372
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library, Delphi - Library
> Reporter: Jens Geyer
> Assignee: Jens Geyer
> Priority: Critical
> Fix For: 0.11.0
>
>
> {quote}Pipe write operations across a network are limited to 65,535 bytes per
> write. For more information regarding pipes, see the Remarks section.{quote}
> Source: [WriteFileEx
> function|https://msdn.microsoft.com/en-us/library/windows/desktop/aa365748(v=vs.85).aspx]
> I managed to run into exactly that limit today. Patch follows.
> Symptom is that
> * the writing end acts as if it had written all the bytes (in fact, it did)
> * but the remainder of ~ 65535 bytes is just lost somewhere and never
> reaches the reading end
> Consequently, the process at the reading end of the pipe gets stuck while
> waiting for the remaining bytes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)