Closed byronhe closed 1 year ago
My point is, do not put global manager related stuff to context_
as it is for that particular Raft instance. Global manager should be retrieved by the singleton only, and should be unique and shared throughout the process.
If you want to avoid inherit nuraft_global_mgr
, then make
nuraft_global_mgr
: base interface class, including static functions for singleton.nuraft_global_mgr_impl
: inherit nuraft_global_mgr
, and move the current default implementation and variables to here.And let your custom class inherit nuraft_global_mgr
. The custom instance should be passed to ngm_singleton::create_custom
function as I mentioned in the previous PR.
+)
Please let me know if what you intended was selectively using different global managers for different Raft instances running in the same process. If that's the case, relying on ctx_
makes sense, and the next discussion needs to be based on that way.
+) Please let me know if what you intended was selectively using different global managers for different Raft instances running in the same process. If that's the case, relying on
ctx_
makes sense, and the next discussion needs to be based on that way.
yes, in our use case, we want assign different global manager to different raft instance, in the same process.
Extract the public interface class global_mgr, so users can provide their own global_mgr implement. so in multi raft instance use scenes, users can do their own performance optimization or multi-global_mgr-in-one-process test.