search

markushedvall / node-plantuml

A Node.js module and CLI for running PlantUML
MIT License
193 stars 53 forks source link

nailgun doesn't work on some installations #15

Open robincooksey opened 7 years ago

robincooksey commented 7 years ago

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 commented 6 years ago

Same!

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

takuyozora commented 5 years ago

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

markushedvall commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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:

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

krisztianb commented 4 years ago

@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. :+1:

krisztianb commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

krisztianb commented 4 years ago

@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.