Uploaded image for project: 'Commons Configuration'
  1. Commons Configuration
  2. CONFIGURATION-530

AbstractFileConfiguration.getProperty(String key) locking causes thread halt

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 1.9
    • Fix Version/s: 2.0
    • Component/s: File reloading
    • Labels:
      None

      Description

      Every call to getProperty causes a lock (related to the reload functionality). In a near real-time system where we have many concurrent threads this affects heavily on the application TPS.

      Possible solution will be: getProperty only returns current value. Reload when needed occurs in a background thread that updates the in-memory map (perhaps by using CopyOnWrite collections?).

        Issue Links

          Activity

          Hide
          oliver.heger@t-online.de Oliver Heger added a comment -

          Unfortunately, there is not yet a concrete release schedule. There are still some important points open which need to be fixed before a release.

          Because of all these incompatible changes (parts of the API have been completely redesigned) it certainly makes sense to get out some alpha or beta releases first to get feedback from the community.

          Show
          oliver.heger@t-online.de Oliver Heger added a comment - Unfortunately, there is not yet a concrete release schedule. There are still some important points open which need to be fixed before a release. Because of all these incompatible changes (parts of the API have been completely redesigned) it certainly makes sense to get out some alpha or beta releases first to get feedback from the community.
          Hide
          yairogen yair ogen added a comment -

          great news. when is this release planned?

          Show
          yairogen yair ogen added a comment - great news. when is this release planned?
          Hide
          oliver.heger@t-online.de Oliver Heger added a comment -

          The anounced changes have now been implemented. A so-called Synchronizer is now used to control concurrent access to a configuration. While the default synchronizer is just a dummy, applications can change it according to their use cases. There is also an implementation of Synchronizer based on the JDK's ReentrantReadWriteLock class.

          Show
          oliver.heger@t-online.de Oliver Heger added a comment - The anounced changes have now been implemented. A so-called Synchronizer is now used to control concurrent access to a configuration. While the default synchronizer is just a dummy, applications can change it according to their use cases. There is also an implementation of Synchronizer based on the JDK's ReentrantReadWriteLock class.
          Hide
          oliver.heger@t-online.de Oliver Heger added a comment -

          There is still a lot to do before version 2.0 is ready. There is no planned release date yet (here in Commons we do not have fix release schedules).

          Show
          oliver.heger@t-online.de Oliver Heger added a comment - There is still a lot to do before version 2.0 is ready. There is no planned release date yet (here in Commons we do not have fix release schedules).
          Hide
          yairogen yair ogen added a comment -

          I understand. When is the planned 2.x release?

          Show
          yairogen yair ogen added a comment - I understand. When is the planned 2.x release?
          Hide
          oliver.heger@t-online.de Oliver Heger added a comment -

          Version 2 will not be backwards compatible, there are some major design changes.

          AFAICT, there is currently no interest in working on the 1.x branch. Also, I am not sure whether the problems related to relading can be changed with reasonable effort and without breaking existing applications.

          Show
          oliver.heger@t-online.de Oliver Heger added a comment - Version 2 will not be backwards compatible, there are some major design changes. AFAICT, there is currently no interest in working on the 1.x branch. Also, I am not sure whether the problems related to relading can be changed with reasonable effort and without breaking existing applications.
          Hide
          yairogen yair ogen added a comment -

          I see. will version 2 be backward compatible? If not - are there any plans on fixing the concurrent access on the 1.x branch?

          Show
          yairogen yair ogen added a comment - I see. will version 2 be backward compatible? If not - are there any plans on fixing the concurrent access on the 1.x branch?
          Hide
          oliver.heger@t-online.de Oliver Heger added a comment -

          Currently, work on a redesigned version 2.0 is going on. This also includes reworking file-based configurations and improved support for concurrent access. There is already code in subversion showing the direction I would like to go. The basic ideas are as follows:

          • Configurations are now created by builder objects.
          • Reloading is moved from configurations to builders. This means, the content of a configuration will not change due to a reload while you work with it. Only if you query the builder again, it might return another configuration instance if a reload was performed in the meantime. So there is no need to synchronize because of possible reloads.
          • It is planed to rework the concept of concurrent access to configuration objects. The idea is to use a similar concept as for Java collection classes: Plain configurations are not thread-safe, but it should be possible to create synchronized configurations if required.
          Show
          oliver.heger@t-online.de Oliver Heger added a comment - Currently, work on a redesigned version 2.0 is going on. This also includes reworking file-based configurations and improved support for concurrent access. There is already code in subversion showing the direction I would like to go. The basic ideas are as follows: Configurations are now created by builder objects. Reloading is moved from configurations to builders. This means, the content of a configuration will not change due to a reload while you work with it. Only if you query the builder again, it might return another configuration instance if a reload was performed in the meantime. So there is no need to synchronize because of possible reloads. It is planed to rework the concept of concurrent access to configuration objects. The idea is to use a similar concept as for Java collection classes: Plain configurations are not thread-safe, but it should be possible to create synchronized configurations if required.

            People

            • Assignee:
              Unassigned
              Reporter:
              yairogen yair ogen
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development