Describe the bug
Potential race condition and data corruption issue in ApplicationContext.java due to the use of global static HashMap structures (applicationMap and resourceBundleMap) that are accessed and modified concurrently by multiple threads. The shared maps are accessed across the JavaFX UI thread and several background jobs such as JobConfigurationServiceImpl, MasterSyncJob, and packet synchronization tasks. Since HashMap is not thread-safe, concurrent read/write operations can lead to:
ConcurrentModificationException
- Data corruption
- Inconsistent application state
- Intermittent UI freezes or crashes
Additionally, the getInstance() singleton accessor lacks synchronization, which may result in double initialization or inconsistent singleton state when multiple threads attempt to initialize ApplicationContext simultaneously.
This issue becomes more visible during simultaneous sync operations while the UI is actively accessing global configuration values.
To Reproduce
Steps to reproduce the behavior:
- Launch the MOSIP Registration Client and log in.
- Initiate a manual "Sync All" operation or wait for multiple scheduled background jobs (e.g., Packet Sync, Master Data Sync) to execute simultaneously.
- While synchronization is running, navigate through the UI or perform actions that access global settings:
- Open Settings
- Start a new registration
- Trigger policy/configuration refresh
- Observe intermittent application freezes or crashes.
- Check logs for
ConcurrentModificationException.
Expected behavior
Global application state and resource bundles should be maintained using thread-safe containers such as ConcurrentHashMap or synchronized access mechanisms to ensure safe concurrent reads/writes across UI and background threads. The Singleton pattern in ApplicationContext should also be implemented with proper synchronization to prevent race conditions during first-time initialization. The application should remain stable and configuration data should stay consistent even when multiple background jobs update shared state simultaneously.
Screenshots
N/A (Backend concurrency/thread-safety issue)
Environment (please complete the following information):
- Server OS: N/A (Client-side issue)
- Client OS : macOS
- Build : master branch
- Browser : Chrome
Attach logs
java.util.ConcurrentModificationException
at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1597)
at java.base/java.util.HashMap$EntryIterator.next(HashMap.java:1630)
at java.base/java.util.HashMap$EntryIterator.next(HashMap.java:1628)
at java.base/java.util.HashMap.putAll(HashMap.java:781)
at io.mosip.registration.context.ApplicationContext.setApplicationMap(ApplicationContext.java:246)
Describe the bug
Potential race condition and data corruption issue in
ApplicationContext.javadue to the use of global staticHashMapstructures (applicationMapandresourceBundleMap) that are accessed and modified concurrently by multiple threads. The shared maps are accessed across the JavaFX UI thread and several background jobs such asJobConfigurationServiceImpl,MasterSyncJob, and packet synchronization tasks. SinceHashMapis not thread-safe, concurrent read/write operations can lead to:ConcurrentModificationExceptionAdditionally, the
getInstance()singleton accessor lacks synchronization, which may result in double initialization or inconsistent singleton state when multiple threads attempt to initializeApplicationContextsimultaneously.This issue becomes more visible during simultaneous sync operations while the UI is actively accessing global configuration values.
To Reproduce
Steps to reproduce the behavior:
ConcurrentModificationException.Expected behavior
Global application state and resource bundles should be maintained using thread-safe containers such as
ConcurrentHashMapor synchronized access mechanisms to ensure safe concurrent reads/writes across UI and background threads. The Singleton pattern inApplicationContextshould also be implemented with proper synchronization to prevent race conditions during first-time initialization. The application should remain stable and configuration data should stay consistent even when multiple background jobs update shared state simultaneously.Screenshots
N/A (Backend concurrency/thread-safety issue)
Environment (please complete the following information):
Attach logs