nailgun doesn't work on some installations

[robincooksey]

With version 0.4.4, on some installations, we find that nailgun doesn't seem
to work - but on others it does.
When it doesn't work, the symptoms are similar to issue #4 - a zero length PNG file is served up. Sometimes, we also see an exception:

   throw err
   ^
Error: read ECONNRESET
   at exports._errnoException (util.js:1018:11)
   at TCP.onread (net.js:572:26)

Commenting out the call to plantuml.useNailgun(); solves the problem, but with the expected performance hit.

We can't find any obvious pattern about which platforms (including versions) it works on - and which it doesn't. E.g., we've seen it both work and not work on different Windows platforms, and likewise on Ubuntu platforms.

I realise this doesn't give a lot to go on, but would it be possible to give me some pointers on debugging this issue further?

[diatech]

Same!

Comment it out works. No idea who to debug either. Frustrating!

[takuyozora]

Same thing here, and it's really slow without NailGun.

[markushedvall]

I've been working on an update to the node nailgun server with improved error handling that hopefully will be able to help finding the source of these kind of problems. I will integrate into node-plantuml in a near future.

[jcayzac]

I'm having this error too, in svg mode. Empty output in Debian Stretch with OpenJDK 8 and ECONNRESET error on Debian Buster with OpenJDK 11. Commenting out nailgun solves it for me too.

[agirorn]

I get ECONNRESET on Linux mint ith "openjdk 11.0.6 2020-01-14" and "Error: connect ECONNREFUSED 127.0.0.1:9999" if I change the port from 0 to 9999.

[agirorn]

Just for the heck of it I maid this https://github.com/agirorn/plantuml module that uses the latest plantuml.jar and does a very simpler exec to start it. When I then plugged that into my project it processed the PlantUML UML faster and with less CPU load in my project.

Also, I believe that after the plantuml.jar process has been started in -pipe mode, you can just feat it with UML one after the other and receive SVGs in the same order and just split them on the newline character or the XML header it starts with. Then where would only be one initial slow start.

Just something to think about if the nailgun continues to be a drag.

[krisztianb]

In case you are interested I've just released another solution for the problem called plantuml-pipe on NPM: https://www.npmjs.com/package/plantuml-pipe

You can use it to generate multiple diagrams with just one JAVA process without having to use a client/server technique. It simply wraps the PlantUML process that is running in pipe.

Many thanks to @agirorn for his help.

[jcayzac]

I've just released another solution for the problem called plantuml-pipe on NPM:

Nice! I just created two issues on your repo to make it a bit more solid. Also, I kind of remember running into a lot of memory leaks when I used PlantUML that way, a problem which didn't seem to affect plantuml-server. I'm curious as if those have been since solved or if you will run into the problem as well.

Me I've taken the heavy artillery out: I'm running plantuml-server as a sidecar to my node process instead, through docker-compose. Using POST requests it's very similar to pipes, since you don't need to deflate/base64 encode anything either.

[krisztianb]

Thank for your feedback.

I haven't run into memory leaks yet. During my tests it looked like that process uses a stable 20 - 40 MB of RAM. But I only tested it generating about 60 class diagrams from which most were small and only few of them bigger.

[jcayzac]

@krisztianb actually after reading your implementation I changed mine to also use pipes yesterday. You can see it here. From testing against my documentation pipeline, which has a lot of UML diagrams --some quite huge, I found:

• The delimiter isn't always accompanied with a newline, so I don't use EOL to split anymore but just trim() the SVG instead.
• -pipeNoStderr is required for errors to be emitted on stdout. I think your implementation ignores errors and treat them as successes, producing the SVG rendering of a PlantUML error instead.
• You need to terminate the input with a newline, for the stream to flush. Otherwise my process would hang indefinitely on some diagrams.

For any serious use you really ought to raise PLANTUML_LIMIT_SIZE. The default value is ridiculously low.

[krisztianb]

@jcayzac many thanks for the reply and information.

For me the EOL has always been there so far. My module also supports binary output (PNG) and not just SVG. So a simple trim() won't do. I'll leave it as it is for the moment.

Regarding -pipeNoStderr you are right. Currently my module does not use this option. So errors are written to stderr and a "faulty" image containing a PlantUML error message is generated for the diagram. For some use cases I think this is not a bad solution. It might be worth adding an option for this though. I'll think about it.

Regarding the newline termination: Yes, it can be seen in the example on the module's README. But it sure can be a gotcha. The module is not going to do this for you. It can't, because it doesn't know when the input data ends. I think it is the job of the module's consumer to take care about this.

Regarding PLANTUML_LIMIT_SIZE: You are right. We already ran into this problem when generating PNG output. I think it does not really make sense to use a pixel graphic format for diagrams, but it might be necessary for devices that can't handle SVG. I'll think about adding an option for this too and also maybe for the max. heap size that you are setting to 4 GB in your code.

Thanks again for your time and giving valuable feedback. It's much appreciated. 👍

[krisztianb]

@jcayzac I might just bumped into what you described as a memory leak. When generating the said about 60 diagrams all seems to go fine up until the very end when the memory usage of the JAVA process jumps from 40 MB up to about 200 MB within a couple of seconds before the process ends.

I would be interested if you see something similar on your side.

[jcayzac]

I would be interested if you see something similar on your side.

No, I'm generating only about 50 diagrams at a time and it seems to hold steady for me. Using plantuml.1.2020.14.jar if that matters.

[krisztianb]

Thanks for reporting back. I'm using V1.2020.15 (28 Jun, 2020). Will check if it depends on the version.

[krisztianb]

@jcayzac just to let you know. I generated the same diagrams using plantuml.1.2020.14.jar and see the same increase in memory usage. Not sure what to do next.