1

I am trying to use GraphViz 2.40.1 under Linux in a REST service that lays out graphs. The service is a Java Spring Boot application. My current approach is to load shared libraries into my JVM, and call native code via JNI, using functions from libraries cgraph and gvc. I'd like to do everything in-memory and avoid file I/O. But I have read the following caveat in the GraphViz lib guide, printed in bold face at the end of section 1: "N.B. Using Graphviz as a library is not thread-safe."

I am seeking help about the consequences I should draw from that statement. No details are given. For example, I can imagine that functions that keep mutable state about errors that have occurred in graph parsing are not thread-safe, but I'm not using these. I only use the following functions: agmemread and agclose from cgraph, and gvContext, gvParseArgs, gvLayout, gvRenderData, gvFreeRenderData, gvFreeLayout, gvFreeContext from gvc. I am caching nothing in Java, local vars and method params only. Would such a use of the library be thread-safe?

If not, does the non-thread-safety only affect uses of single functions, not across functions? So would it be enough to make my Java native methods static synchronized? Or would I have to synchronize on every REST request?

Alternatively, I could fork a new OS process for each request and do file operations with GraphViz's dot program with Runtime.exec().

What approach would scale best?

Sebastian
  • 315
  • 2
  • 12
  • BTW, I have searched the GraphViz issues on GitLab and come up with issue 1282. A comment there states: "many functions rely on static global or local variables, starting with the lexer and parser, including many of the layout phases and utility algorithms, and through output. To be safe, access to all of these would need to be protected by a lock or converted into explicit state data handed to the functions as an argument." But this is 2 years old. Though the issue is still open, perhaps much has changed inside GraphViz since then. – Sebastian Oct 21 '19 at 14:48
  • I would be worried. You are only going to get one copy of the library per JVM instance, so any global memory in that library will only exist once. If your web-server is running a persistent JVM (which it probably is) I would be concerned with multiple concurrent requests would cause issues with the global variables. You could work around the issue with a semaphore around the jni usage for this library or spin up the lib as a separate process so that only one instance can ever be used. Debugging thread safety issues through JNI is not fun. – Alex Barker Oct 22 '19 at 23:15
  • Thanks for the warning, I'll proceed with using the lib in a separate process. – Sebastian Oct 23 '19 at 09:35

0 Answers0