Domino 14: OutOfMemoryError: Java heap space #329
Comments
|
Hmm, interesting, and your suspicion on where it's going awry is presumably correct. I wonder if there's something about the changed JVM or library code that makes the process not realize it's done the "JSON" part and on to the "binary" part. I'll have to see if I can reproduce it. It didn't happen with the example projects in the repo for me, but maybe it's only after the compiled NSF ends up a certain size or above. |
|
I found a project that reproduces it, but it makes the situation thornier: it looks like the trouble is that the call to compile LotusScript in a note will crash the server given some combination of input, even though the same won't happen on 12.0.2. I see this stack from the NSD: That's lower-level than anything I'm explicitly doing, and it seems like it's dying during parsing. I'll have to try to track down if there's a specific construct in LotusScript that causes this, which would be ideal for a support case. That could be a long process, though, since the app I picked has a huge amount of LS code in it. |
|
Oh: it's also on Linux specifically for me. 14.5 EAP1 on Windows worked without issue for me, while 14.0 and 14.5 EAP1 crash on Linux in containers. |
|
Ah, some good news! I was able to narrow it down to a single library, and it's a common one at that: this NSF uses OpenLog, and OpenLogFunctions reliably crashes the server when I add it to an ODP that was previously working fine. Even better, OpenLogFunctions has no external |
|
Hey Jesse, thank you for the support. I'm not sure if it helps but we use SLF4J for logging |
|
Since it seems like yours dies on "basic design elements", it could be that you have something in there that trips up the parser in the same way as OpenLog does. Do you see NSDs from server crashes around when you try this compilation? That could help prove that it's the same problem, especially if you see "NSFNoteLSCompileExt" or "LSCompileNoteExt" anywhere in there. |
|
i'll try to get the nsd when i'm back from a business trip on saturday and get back to you |
|
I also see |
|
Excellent, thank you. And that one comes from a slightly-different path to the same end, since that happens during the DXL import. Presumably, that means it’d be reproducible using just the normal LotusScript or Java API, removing another layer of user code in the stack - always a plus when narrowing things down. |
|
Is there something where I can help? |
|
It’s in HCL’s hands for now - I opened a support ticket a few weeks ago and they’ve been looking at it since. |
Dear Jesse,
after you fixed #327, I was able to continue compiling the project. However, after a few minutes an error occurred and Domino crashed.
This is the maven output:
Then after some minutes Domino crashes and i get this error (while using the
-eflag for maven). I was not able to increase the heap space.I'm not really sure, but this seems to be a place in the code that receives the successful build after the POST request.
With Domino 12 we get an nsf of about 70mb.
The text was updated successfully, but these errors were encountered: