Bug: Timeout in large diagram from Doclet

+1 vote
asked Jun 5 in Bug by Bob Jacobsen

Using the new UmlDoclet with Java 11 on a big project, we're getting timeouts.  Many of the files are processed OK, but some large diagrams get this exception:

  [javadoc] java.lang.IllegalStateException
  [javadoc]     at net.sourceforge.plantuml.svek.Bibliotekon.getNodeUid(Bibliotekon.java:127)
  [javadoc]     at net.sourceforge.plantuml.cucadiagram.Link.getEntityPort1(Link.java:251)
  [javadoc]     at net.sourceforge.plantuml.svek.Line.<init>(Line.java:227)
  [javadoc]     at net.sourceforge.plantuml.svek.GeneralImageBuilder.buildImage(GeneralImageBuilder.java:373)
  [javadoc]     at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFileInternal(CucaDiagramFileMakerSvek.java:102)
  [javadoc]     at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFile(CucaDiagramFileMakerSvek.java:66)
  [javadoc]     at net.sourceforge.plantuml.cucadiagram.CucaDiagram.exportDiagramInternal(CucaDiagram.java:646)
  [javadoc]     at net.sourceforge.plantuml.classdiagram.ClassDiagram.exportDiagramInternal(ClassDiagram.java:188)
  [javadoc]     at net.sourceforge.plantuml.UmlDiagram.exportDiagramNow(UmlDiagram.java:196)
  [javadoc]     at net.sourceforge.plantuml.AbstractPSystem.exportDiagram(AbstractPSystem.java:130)
  [javadoc]     at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:153)
  [javadoc]     at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:125)
  [javadoc]     at nl.talsmasoftware.umldoclet.uml.Diagram.renderDiagramFile(Diagram.java:172)
  [javadoc]     at nl.talsmasoftware.umldoclet.uml.Diagram.render(Diagram.java:132)
  [javadoc]     at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
  [javadoc]     at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
  [javadoc]     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
  [javadoc]     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
  [javadoc]     at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
  [javadoc]     at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
  [javadoc]     at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
  [javadoc]     at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
  [javadoc]     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
  [javadoc]     at nl.talsmasoftware.umldoclet.UMLDoclet.run(UMLDoclet.java:130)
  [javadoc]     at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:582)
  [javadoc]     at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:431)
  [javadoc]     at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:344)
  [jahttps://github.com/JMRI/JMRI/pullsvadoc]     at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63)
  [javadoc]     at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52)

We were generating SVG files as output. 

A Issue was raised on the UmlDoclet GitHub, including instructions to recreate.  Basically, you check out the JMRI project from GitHub, and do "ant javadoc-uml".  They were able to recreate and suggested filing a bug here.

It might be that there just needs to be a way to length that timeout...

I have a .puml file that can recreate it when run directly with PlantUML, but I don't see how to attach it. It can be picked up from https://github.com/talsma-ict/umldoclet/files/4733933/package-dependencies.puml.zip

Thank you!

1 Answer

0 votes
answered Jun 15 by matthjes (160 points)

Hi,

I've run into the same bug, but there is a -timeout N parameter. Maybe you can run plantuml with, e.g. -timeout 2000 to generate the diagram. This sets the timeout to 2000 seconds, compared to the 900 seconds (15 minutes) default. I'm testing it currently.

...