Metro 2.3.1, Java 8 update 121, StreamingDataHandler Java Heap Space

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Metro 2.3.1, Java 8 update 121, StreamingDataHandler Java Heap Space

joeysr20det
This post has NOT been accepted by the mailing list yet.
It appears that since we updated to Java 8 we are now experiencing Java Heap Space issues using the StreamingDataHandler to stream in large incoming attachments. In the past (several years) we've never had issues with this, but recently even a very small attachment of just 100-200MB is enough to run out of memory. For instance, a 221 MB test file that previously worked with no noticeable change in JVM memory usage now easily causes a 600-900MB consumption before ultimately exceeding the 2GB heap space.

I've been through the gambit searching on this. Yes I've boosted the heap space to 3GB-4GB to get past this; but that is hardly a fix. It appears as though the best I can tell, it doesn't matter if I use the StreamingDataHandler's moveTo or readOnce method (and do the file copy myself) the issue appears when I call the close() method. For grins, I've tried just using the plain getInputStream on the base DataHandler object as well as all of the above on using org.jvnet.staxex.StreamingDataHandler instead of the suggested com.sun.xml.ws.developer.StreamingDataHandler. It doesn't seem to matter what I try, there doesn't appear to be a way around this.

As I said previously we could easily accept attachments 1GB in size without issue. If I need to add 1GB/2GB of additional heap space for a measly 200MB file, I can't imagine what I would need to handle a 1GB file.

In short, it's very apparent that there is some sort of issue here and I don't feel very re-assured as Metro 2.3.1 is 2 years old now. It looks like there hasn't been a nightly build in about a year either.

Anybody have any insight on this issue?

Anybody know if this project is still active?

Thank you

Joey