Config file reload concurrency when invoked via HTTP server
The HTTP server https://github.com/prometheus/client_java/blob/master/simpleclient_httpserver/src/main/java/io/prometheus/client/exporter/HTTPServer.java runs a pool of 5 serving threads, so metric collection can be invoked concurrently, or at least from different threads.
The design already seems to reflect this (see ConcurrentHashMap in the JmxMBeanPropertyCache), though some explicit remarks would be nice to have.
It seems config, configFile are not accessed synchronized, so they might be stale in different threads. On a quick eyeballing, it should still reload the config file fine per-thread, but why risk the ambiguity.
I'm confused, are you reporting a bug in our concurrency handling and if so can you state exactly where the race is?
Ah, sorry, was too entrenched in the context and omitted it. If I read it correctly, it's the collect method which can be called concurrently via the pooled http server. There, access to config field (via read of the lastUpdate and setting by reloadConfig) is not synchronized, which can lead to visibility issues between threads.
See https://github.com/prometheus/jmx_exporter/blob/master/collector/src/main/java/io/prometheus/jmx/JmxCollector.java#L457
Yeah, that looks like a race alright.