after testing out the downloading big pdf file which i had issues with i notice the wrapper log would give a error

INFO | jvm 1 | 2009/08/19 00:14:37 | Exception in thread "OEEngineServerThread" java.lang.OutOfMemoryError: Java heap space

INFO | jvm 1 | 2009/08/19 00:14:37 | at java.lang.AbstractStringBuilder.(Unknown Source)

INFO | jvm 1 | 2009/08/19 00:14:37 | at java.lang.StringBuilder.(Unknown Source)

INFO | jvm 1 | 2009/08/19 00:14:37 | at com.revelation.oesocketserver.OEngine.m(OEngine.java:469)

INFO | jvm 1 | 2009/08/19 00:14:37 | at com.revelation.oesocketserver.OEngine.a(OEngine.java:379)

INFO | jvm 1 | 2009/08/19 00:14:37 | at com.revelation.oesocketserver.j.a(Unknown Source)

INFO | jvm 1 | 2009/08/19 00:14:37 | at com.revelation.oesocketserver.j.a(Unknown Source)

INFO | jvm 1 | 2009/08/19 00:14:37 | at com.revelation.oesocketserver.h.run(Unknown Source)

now this error comes from OEngine.java file at line 489 its a issue with java and strings since there are array and objects. so Strings are memory hogs thats why you have to up the memory heap, after doing a bunch of research i would recommend changing that line of code from s2=(new StringBuilder()).append(s2).append(s3).toString() to either do a loop in chunks of the text or as a java developers recommend to me with large string create a file that appends the strings then load the file. I'm actually testing this out i tried setting the capacity of the string and append to hopefully save some memory no help so im going to try the chunk loop then file.

also the wrapper.exe is updated to 3.3.5 I recommend update even though there hasn't been issues with it they have made major changes to make logging faster and more efficient

Hi, Jensen. Did you just try increasing the java heap at startup time? That was the solution that appeared to work for others trying to send and receive large chunks of data.

Thanks,

- Bryan Shumsky

Revelation Software

I got large files to work with oecgi.php basically by doing partial content but that only works for pdf and other apps that can request chunks of information. Im just writing this not as a issue but more of you might want to look into this. Increasing heap size to the max of 2048 to stop java from running out of memory is something i don't want as a solution if the cause is by coding that can be changed. right now I am changing the coding in OESocketServer.jar to see if doing the coding to handle large strings with help rather the increasing heap size. I already tried by increase the capacity of the string first then appending it but still ran out of memory so today i was going to try today to Split the String in chunks and append doing that i can flush the content after so many bytes to help with the memory consumption.

If you want to tow large loads, you have to pump up the tires.

Who are you - and what have you done with Eric? ;)

cpates@sprezzatura.com

Captain's Blog

I'm perfectly safe. Just trying to get my lips around the inner tube valve. Then again, I don't have lips…

I got some good news and some bad. I got the OESocketServer.jar to pass a 25MB file without increasing the heap, but to make it work i had to do string concatenation in a file then read the file. bad new I should of put elapsed times on the System.out.prinln because apperantly the Native function in RevJapi.dll takes to long to spit out the file it took like 426 seconds to send java the information then you starting appending the deliminating chars which would cause the out of memory. which can be stop by doing string concats in a file. anyway it looks like there really is no solution to passing large file with OECGI2. you can do it with the OECGI2.php by doing partial content.

View this thread on the forum...