terrymanu commented on issue #37714:
URL:
https://github.com/apache/shardingsphere/issues/37714#issuecomment-3737796026
Issue Understanding
- Reporter sees static EVENT_LISTENER_EXECUTOR in
mode/type/cluster/repository/provider/etcd/EtcdRepository.java:63 and close()
shutting it down at ~204, fearing multiple EtcdRepository instances in one JVM
will break each other and cause classloader leaks.
- Repro described: create EtcdRepository A and B in same JVM, close A,
then watch on B fails with RejectedExecutionException.
Root Cause
- The static single-thread executor is shared by all EtcdRepository
instances and is shutdown() inside the instance-level close(). In a
multi-instance-in-same-JVM or “close then recreate” scenario, later watch
callbacks will be rejected because the shared executor is already shut down.
- ShardingSphere cluster mode is designed for one repository instance per
JVM: ClusterContextManagerBuilder#getClusterPersistRepository creates one SPI
instance, and ContextManager.close() closes the repository when the whole
process is shutting down. Under that usage, shutting down the executor matches
lifecycle expectations.
Analysis
- Watch callbacks submit via CompletableFuture.runAsync(...,
EVENT_LISTENER_EXECUTOR); if any instance calls close(), subsequent dispatches
on any other instance in that JVM will be rejected. This requires multiple
EtcdRepository objects or restart-within-same-JVM
usage, which is outside the normal deployment pattern.
- The executor is daemon and closed on close(), so with the typical
single-instance lifecycle there is no lingering thread or classloader
retention; the reported leak risk only appears with hot-redeploy or custom
multi-instance patterns not covered by the current design.
- Current code lacks safeguards for same-JVM multi-instance or
reinit-after-close; behavior is undefined there but aligns with the documented
single-instance expectation.
Conclusion
- Under official usage (one EtcdRepository per JVM in cluster mode), the
static executor shutdown is consistent with the intended lifecycle and should
not affect running components; the described failure arises only from
non-standard same-JVM multi-instance or restart patterns.
- To judge whether the design should be extended, please provide: (1)
Actual runtime topology (Proxy or JDBC? multiple Mode/EtcdRepository instances
or hot-reload in the same process?); (2) Full stack trace and call chain for
the RejectedExecutionException; (3) Exact init/close sequence and code snippet;
(4) Whether your goal is to support multiple repositories in one JVM or
repeated start/stop in the same process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
