ConcurrentModificationException thrown when adding/modifying graph templates for resource types that are being used
Description
I've discovered a weird problem when modifying some graph templates that are being in use, i.e., modifying templates after generating a resource graph report through the WebUI.
The problem seems to be related with adding brand new templates or modifying the name of an existing templates by adding numeric digits on their names, for resource types that are being in use.
Here is an example of how to reproduce the problem:
Choose a resource type to test. I’ve chosen "interfaceSnmp" and the templates defined on mib2-graph.properties for testing purposes.
Generate a resource graph report for any interface (it doesn't matter which kind of node is being monitored).
Edit the templates pages and rename mib2.bits to mib2.aa.bits, and mib2.HCbits to mib2.aa.HCbits. Of course, all references to the old names must be updated as well.
Be sure about the changes, and save the file.
After reloading the resource graph page, the graphs are OK. That means, adding “letters” to the names of graphs that are being in use it not a problem. No exceptions found.
Now, edit the template again but changing mib2.HCbits to mib2.00.HCbits and mib2.bits to mib2.01.bits (remember to update all the references like on step 3 and 4).
After reloading the resource graph page, the ConcurrentModificationException is thrown, and from now on, the reload operation for the graph templates is broken until you restart OpenNMS. I've also noticed that the graphs that I've modified are appearing twice, but because the reload operation is broken, OpenNMS must be restarted after fixing the templates file.
Here is a second use case:
Before start, I've restored the file to its original content, stop OpenNMS, delete the logs and start again.
Choose a resource type to test. I’ve chosen "interfaceSnmp" and the templates defined on mib2-graph.properties for testing purposes.
Generate a resource graph report for any interface (it doesn't matter which kind of node is being monitored).
Edit the templates pages and create a new graph based on mib2.bits called for example mib2.00.bits. You can change the colors and some some styles on the graph to make it look a little bit different from mib2.bits.
Be sure about the changes, and save the file.
After reloading the resource graph page, the ConcurrentModificationException is thrown, and from now on, the reload operation for the graph templates is broken until you restart OpenNMS.
So, for some reason, if the name of currently used graph templates are modified to include digits or new graphs are added with digits on their names after starting OpenNMS, that will break the ability to make changes on the graph templates, and OpenNMS must be restarted to fix the problem.
The web.log is attached to show the whole stack trace of the exception.
Environment
An CentOS 7 VM running OpenNMS 14.0.2 installed through RPM using PostgreSQL 9.2 and Oracle Java 7u71
Acceptance / Success Criteria
None
Attachments
1
Lucidchart Diagrams
Activity
Show:
Benjamin Reed January 7, 2015 at 11:14 AM
OK, I believe I've fixed this in the release-14.0.3 branch by changing all maps to use ConcurrentMaps, and making copies of Sets and Lists where appropriate to avoid concurrency issues.
I've discovered a weird problem when modifying some graph templates that are being in use, i.e., modifying templates after generating a resource graph report through the WebUI.
The problem seems to be related with adding brand new templates or modifying the name of an existing templates by adding numeric digits on their names, for resource types that are being in use.
Here is an example of how to reproduce the problem:
Choose a resource type to test. I’ve chosen "interfaceSnmp" and the templates defined on mib2-graph.properties for testing purposes.
Generate a resource graph report for any interface (it doesn't matter which kind of node is being monitored).
Edit the templates pages and rename mib2.bits to mib2.aa.bits, and mib2.HCbits to mib2.aa.HCbits. Of course, all references to the old names must be updated as well.
Be sure about the changes, and save the file.
After reloading the resource graph page, the graphs are OK. That means, adding “letters” to the names of graphs that are being in use it not a problem. No exceptions found.
Now, edit the template again but changing mib2.HCbits to mib2.00.HCbits and mib2.bits to mib2.01.bits (remember to update all the references like on step 3 and 4).
After reloading the resource graph page, the ConcurrentModificationException is thrown, and from now on, the reload operation for the graph templates is broken until you restart OpenNMS. I've also noticed that the graphs that I've modified are appearing twice, but because the reload operation is broken, OpenNMS must be restarted after fixing the templates file.
Here is a second use case:
Before start, I've restored the file to its original content, stop OpenNMS, delete the logs and start again.
Choose a resource type to test. I’ve chosen "interfaceSnmp" and the templates defined on mib2-graph.properties for testing purposes.
Generate a resource graph report for any interface (it doesn't matter which kind of node is being monitored).
Edit the templates pages and create a new graph based on mib2.bits called for example mib2.00.bits. You can change the colors and some some styles on the graph to make it look a little bit different from mib2.bits.
Be sure about the changes, and save the file.
After reloading the resource graph page, the ConcurrentModificationException is thrown, and from now on, the reload operation for the graph templates is broken until you restart OpenNMS.
So, for some reason, if the name of currently used graph templates are modified to include digits or new graphs are added with digits on their names after starting OpenNMS, that will break the ability to make changes on the graph templates, and OpenNMS must be restarted to fix the problem.
The web.log is attached to show the whole stack trace of the exception.