Follow up to an old problem, finally solved, in case anyone else<br>stumbles across the same problem.<br><br>> I have a problem with a storage web service our group wrote using<br>> <span class="nfakPe">Mongrel</span>::HttpHandler We have a consistent problem when using<br>
> http PUT to this service when the data is larger than about 4 GB.<br><br>Well, it turns out I could only repeat it consistently between two<br>particular systems. There was some back and forth on this<br>list, and I threw out the red herring that the http11_parser.c code<br>
used an unsigned int for the content size. Zed pointed out that <br>particular variable was just dead code:<br><br>> Instead you have this line in http_request.rb:<br>
> <br>> content_length = @params[Const::CONTENT_LENGTH].to_i<br><div id="1hcp" class="ArwC7c ckChnd">
><br>> Now, that means it relies on Ruby's base integer type to store the<br>
> content length:<br><br>Since @params[Const:CONTENT_LENGTH] is a string, ruby's<br>to_i method can get it right, casting to a fixnum internally when <br>necessary - integer overflow was not the issue.<br></div>
<br><br>On Tue, Jun 3, 2008 at 8:30 PM, Michael D'Auria<br>
<<a href="mailto:michael.dauria@gmail.com">michael.dauria@gmail.com</a>> wrote:<br>
> Randy,<br>
> Are you sure this is an issue with the size of the input and not the amount<br>
> of time that the connection is left open?<br>
> Michael<br><br>That turns out to be the correct answer, though I eliminated it (incorrectly)<br>by using curl's limit-bandwidth option to get times greater than that<br>exhibited by my 4GB transfers - those all worked.<br>
<br>What was causing the problem was the lag between the end of the <br>upload/request from the client, to the time when the server finally <br>sent a response after processing the request (the processing time was <br>entirely taken up with copying the upload as a temporary mongrel <br>
file to its permanent disk file location).<br><br>Still, using tcpdump showed that the response was making it back <br>to the client from the server intact and correctly.<br><br>What was timing out was the firewall on the client system, which <br>
was using statefull packet filtering (iptables on an oldish redhat <br>system). The dead time in the http request/response had <br>exceeded the time to live for the state tables. Turning off the <br>keep-state flag in the firewall rules allowed the transfer to<br>
complete. Now it's just a matter of tweaking the parameters so <br>we can get keep-state working again.<br><br>Thanks for all the help on this.<br><br>-Randy Fischer<br>