Foren
ConcurrentModificationException: Race condition in HotDeployEvent processin
Tor Iver Wilhelmsen, geändert vor 14 Jahren.
ConcurrentModificationException: Race condition in HotDeployEvent processin
Junior Member Beiträge: 60 Beitrittsdatum: 03.12.08 Neueste Beiträge
Environment: Webspace 10.0.6/Liferay 5.2.3 running on Glassfish 2.1
We are getting occasional startup troubles which manifest as a ConcurrentModificationException when firing premature events. What seems to happen is:
However, because of point 4, the processing loop in point 3 will exit with a ConcurrentModificationException due to the events added to the list after the iterator loop started.
Would it be an idea to modify _flushPrematureEvents() to make a local reference to _prematureEvents, null it, then start the processing? Then we would avoid the issue of the ConcurrentModificationException at least.
An second option could be to replace the use of the iterable to use an "oldfashioned" for-loop that tested on size() - this would deal with the case where events got added because the size() would increase.
A third would be that _flushPrematureEvents() was synchronized on the same object that also guarded the statements in _fireDeployEvent(). Then events fired during the flushing step would wait until the flusing was finished, and then would fire immediately since the list is null when they get to run. The two preceding solutions have a very small (but greater than zero) for still having a race condition which synchronized blocks would avoid.
Any ideas?
We are getting occasional startup troubles which manifest as a ConcurrentModificationException when firing premature events. What seems to happen is:
- App-server startup fires up web applications
- As a consequence of starting, plugin webapps start registering in Liferay using fireDeployEvent(). This adds to the _prematureEvents list for now.
- Liferay's MainServlet comes to the end of its initialization and starts processing the premature events in _flushPrematureEvents()
- Some late-ish threads continue to register events. Since MainServlet has not finished flusing and nulling the list, they get added to it.
- At the end of _flushPrematureEvents, the list is nulled. Deploy events fired after this will fire immediately.
However, because of point 4, the processing loop in point 3 will exit with a ConcurrentModificationException due to the events added to the list after the iterator loop started.
Would it be an idea to modify _flushPrematureEvents() to make a local reference to _prematureEvents, null it, then start the processing? Then we would avoid the issue of the ConcurrentModificationException at least.
An second option could be to replace the use of the iterable to use an "oldfashioned" for-loop that tested on size() - this would deal with the case where events got added because the size() would increase.
A third would be that _flushPrematureEvents() was synchronized on the same object that also guarded the statements in _fireDeployEvent(). Then events fired during the flushing step would wait until the flusing was finished, and then would fire immediately since the list is null when they get to run. The two preceding solutions have a very small (but greater than zero) for still having a race condition which synchronized blocks would avoid.
Any ideas?
Tor Iver Wilhelmsen, geändert vor 14 Jahren.