[GitHub] [flink] guoweiM commented on issue #11196: [FLINK-16246][connector kinesis] Exclude AWS SDK MBean registry from Kinesis build
guoweiM commented on issue #11196: [FLINK-16246][connector kinesis] Exclude AWS SDK MBean registry from Kinesis build URL: https://github.com/apache/flink/pull/11196#issuecomment-593172858 There is no addition. Thanks for your patient explanation. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [flink] guoweiM commented on issue #11196: [FLINK-16246][connector kinesis] Exclude AWS SDK MBean registry from Kinesis build
guoweiM commented on issue #11196: [FLINK-16246][connector kinesis] Exclude AWS SDK MBean registry from Kinesis build URL: https://github.com/apache/flink/pull/11196#issuecomment-592934606 @StephanEwen I agree that the singleton is scoped to the Class and the Class could be loaded multi-times by the different classloaders. This also leads to “many” singleton objects in the JVM scope. In Flink, these may be the normal case because Flink uses the FlinkUserClassLoader. However, I think if we could provide some mechanism that guarantees that the singleton library could be only loaded once in a JVM. This could lead to only one singleton object. There might be different versions of the library but the number might very limited compared to the failover and many new jobs. The con of this option is how to get this target without many efforts from the user in all the scenarios. But in my experience, the connector normally has very heavy dependence libraries and normal leads to leak something. So in the connector scenarios, we could provide some mechanisms such as plugin to reach this goal. The pro of this option is that this is a general method. The user does not pay much effort to resolve this problem. Even if we provide some method for user to clean up the resource, the user should pay some efforts to clean up theses resource. Sometimes it is possible. Some time it is very difficult for the user to do it. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [flink] guoweiM commented on issue #11196: [FLINK-16246][connector kinesis] Exclude AWS SDK MBean registry from Kinesis build
guoweiM commented on issue #11196: [FLINK-16246][connector kinesis] Exclude AWS SDK MBean registry from Kinesis build URL: https://github.com/apache/flink/pull/11196#issuecomment-592548023 In response to this problem, I think there are two ideas. One is the idea of cleaning up. Everyone has said it in more detail, and I have n’t added anything. There is another idea is to keep the singleton. Some third-party libraries have the design philosophy. There must be individual singleton objects, and these objects are consistent with the life cycle of the JVM. In this case, if we can guarantee that these singleton objects in a TM do not increase with the increase of Task, is it acceptable? In this way, we can also avoid case-by-case resolution. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
