Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-1852

If a global component fails to start during cache startup, future getCache calls for that cache will never return

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Critical
    • 5.1.2.CR1, 5.1.2.FINAL
    • 5.1.1.FINAL
    • Core
    • None

    Description

      In DefaultCacheManager, before starting a cache we register a CacheWrapper with the cache name, and subsequent calls to getCache(cacheName) will wait for a countdown latch in the CacheWrapper to confirm that the cache has finished starting.

      However, if a global component fails to start, that latch is never opened - so future calls to getCache(cacheName) will block forever.

      If startCaches() is used to start multiple caches at once, the global start exception will be on a background thread and the user will only notice that the getCache calls on the main thread never return.

      This situation appeared in the hibernate-search test suite, which extended JGroupsTransport to change the cluster name to a unique value on startup. The cluster name is not dynamic in 5.1, so the global component registry failed to start.

      Attachments

        Activity

          People

            dberinde@redhat.com Dan Berindei (Inactive)
            dberinde@redhat.com Dan Berindei (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: