[
https://issues.jboss.org/browse/ISPN-9627?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-9627:
------------------------------------
[~pferraro] I created the issue, but the more I think about it, the more I'm convinced
that listeners should be stopped **before** stopping the cache manager, or not at all.
If one thread stops the cache manager and another tries to remove a listener, the only way
to avoid throwing a {{IllegalLifecycleStateException}} from {{removeListener()}} would be
to actually catch {{IllegalLifecycleStateException}}, and that seems too much like a hack.
Allowing {{removeListener()}} after {{stop()}} might also give the user the impression
that listeners are normally preserved across {{stop()}} and {{start()}}, which is not the
case.
Removing a listener after cache manager stop throws an exception
----------------------------------------------------------------
Key: ISPN-9627
URL:
https://issues.jboss.org/browse/ISPN-9627
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Major
Fix For: 9.4.1.Final
{{DefaultCacheManager.removeListener()}} needs the {{CacheManagerNotifier}} component and
fails if the component can't be accessed, e.g. because the manager is stopped. Since
listeners are removed automatically on stop, a {{DefaultCacheManager.removeListener()}}
call after stop should be a no-op.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)