Thread safety
Monitor Java applications - SQL, HTTP, Methods, Exceptions and more.
Brought to you by:
stevesouza
It appears that Jamon does not give the correct results when used with multiple threads on a multiprocessor machine. I'm assuming it's intended to be used with multiple threads because of the "active" counter. Is it possible that variable visibility in a multiprocessor context is not correctly implemented? I have been able to reproduce the problem in a small test case. Synchronizing access to the monitor ("add" method) fixes the concurrency problem. I'm not suggesting this as the final solution since it might cause performance issues, but it does seem to verify the threading issue.
Logged In: YES
user_id=1063786
Originator: NO
I ran into the same prob.
It seems that the TimeMon is not threadsafe:
Having multiple Threads starting and stopping the same monitor instance, the TimeMon does not correlate the start() and the stop() invocations.
The above suggested solution might not really solve that prob !?
I suggest: The "active" counter should be something static:
Either the Monitor class or the MonitorFactory should count 'active' Monitors having the same key.
It should be impossible to start an 'active' Monitor - maybe start() should throw an IllegalStateException
BR
Boris