Skip to content

[BUG] Fix non-thread-safe global state and race conditions in ApplicationContext #793

Description

@CodeBySayak

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:

  1. Launch the MOSIP Registration Client and log in.
  2. Initiate a manual "Sync All" operation or wait for multiple scheduled background jobs (e.g., Packet Sync, Master Data Sync) to execute simultaneously.
  3. 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
  4. Observe intermittent application freezes or crashes.
  5. 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)

Metadata

Metadata

Labels

duplicateThis issue or pull request already existsinvalidThis doesn't seem rightwontfixThis will not be worked on

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions