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

Reply via email to