[ 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)