One of our customers has reported a CuncurrentModicationException during system start up: 2015-02-03 12:45:10.049 SEVERE Exception while saving server table java.util.ArrayList.writeObject(ArrayList.java:766) sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ... org.jacorb.imr.ImplementationRepositoryImpl.save_server_table(ImplementationRepositoryImpl.java:825) This is a manifestation of a race condition that exists between the WriteThread, which serializes the server_table to disk, and the thread calling register_poa() with a new POA. While adquate locking is provided for the fields in the ServerTable class through its table_lock, the call to _server.addPOA(_poa); while registering a new POA does not fall into the scope of that lock. This bug was reported against an older version of JacORB, JacORB 2.3.1. However, by reviewing the code in the latest head of the upstream, I see that it is also present there. I will attach a patch that introduce a new lock to prevent the ConcurrentModificationException. -- Weiqi Gao Principal Software Engineer Object Computing, Inc.
Created attachment 457 [details] This patch introduces a ResourceLock to prevent a race condition described in the but report.
Given ResourceLock is isolated to the IMR its fine to keep using it I think. Can you produce a junit regression test for this? (byteman?) Can you supply a pull request via github?
Fixed by SHA 3753b586bac0b1e23fb578726cb4e927e535dc01