Jason,<br><br> Would you like me to take a look/confirm where the issue is or are we planning on using Ike's patch (I would vote for Ike's patch, as the Apache library is most likely much more robust than my cobbled together solution ;) ).<br>
<br>Thanks,<br><br>--Jonathan<br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 9:55 AM, Jason T. Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Yeah glancing at the code the problem is likely in the header parsing.<div class="im"><br>
<br>
On 4/15/11 7:17 AM, Jonathan Pearlin wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Ike,<br>
<br>
One more thing to add: when I wrote the smoke tests for the upload<br>
API, I did notice a similar issue. However, it turned out that I was<br>
not creating the multipart POST correctly (an error in how I was<br>
programmatically building the multipart was cauing the parsing to enter<br>
into an infinite loop and run out of memory). However, once I fixed the<br>
test code to produce a valid multipart post, everything was fine. In my<br>
normal development testing, I tested by uploading the Hudson WAR file<br>
(which is about 34 MB and much larger than the one you see the issue<br>
with). However, while it is possible that this issue is due to whatever<br>
is submitting the upload request not following the multipart<br>
specification, the code probably does need to be changed to handle<br>
multipart requests that do not contain completely valid data (if we<br>
cannot use the Apache library). I would be curious to see what the POST<br>
looks like that is causing the issue (in terms of the mutlipart<br>
boundary, header and payload). It is fairly easy to modify the server<br>
code to dump the incoming POST request to a file to see if it is at all<br>
different than what is expected.<br>
<br>
Thanks,<br>
<br>
--Jonathan<br>
<br>
On Fri, Apr 15, 2011 at 8:07 AM, Jonathan Pearlin <<a href="mailto:jpearlin1@gmail.com" target="_blank">jpearlin1@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:jpearlin1@gmail.com" target="_blank">jpearlin1@gmail.com</a>>> wrote:<br>
<br>
Ike,<br>
<br>
I actually looked at using the Apache library (instead of<br>
writing my own) when I started, but did not follow that path simply<br>
because of the potential licensing issues. However, if Jason agrees<br>
that it is okay to go down that path, I would love to replace the<br>
custom multipart parsing code with a more mature library. That<br>
being said, the multipart parsing currently relies on a library<br>
Jason wrote a while back to treat the incoming stream as multipart<br>
data. I can certainly try digging into this to see if I can<br>
pinpoint what is causing the OOM issue (if it is in the HTTP server<br>
code itself or in the multipart stream class).<br>
<br>
Thanks,<br>
<br>
--Jonathan<br>
<br>
<br>
On Fri, Apr 15, 2011 at 7:50 AM, Heiko Braun <<a href="mailto:hbraun@redhat.com" target="_blank">hbraun@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:hbraun@redhat.com" target="_blank">hbraun@redhat.com</a>>> wrote:<br>
<br>
<br>
<br>
<br>
I've run into a OOM issue when uploading content through the<br>
HTTP API again.<br>
(<a href="https://issues.jboss.org/browse/JBAS-9268" target="_blank">https://issues.jboss.org/browse/JBAS-9268</a>)<br>
<br>
<br>
I did take a look at the current implementation and propose that<br>
we change it in the following way:<br>
<br>
- read multipart contents from mime boundary<br>
- replace the custom multipart stream implementation with a<br>
mature one (leans on apache commons fileupload)<br>
<br>
I've got this changes tested and verified in a custom branch:<br>
<a href="https://github.com/heiko-braun/jboss-as/commits/out_of_memory" target="_blank">https://github.com/heiko-braun/jboss-as/commits/out_of_memory</a><br>
<br>
However before going ahead, I would like get some feedback from<br>
<br>
a) the original author (Jonathan Pearlin. Welcome onboard btw)<br>
b) Jason wrt the Apache License sources (See<br>
org.jboss.as.domain.http.server.multipart.asf.*)<br>
<br>
<br>
Regards, Ike<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
jboss-as7-dev mailing list<br></div>
<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.jboss.org</a> <mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.jboss.org</a>><div class="im">
<br>
<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
jboss-as7-dev mailing list<br>
<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
</div></blockquote><font color="#888888">
<br>
<br>
-- <br>
Jason T. Greene<br>
JBoss, a division of Red Hat<br>
</font></blockquote></div><br>