I have tried to remove it for a while but someone claims he has used it. Make it again and try to review it! It can also remove some logic in interpreterFactory, too. May I handle it?
On Thu, May 11, 2017 at 7:53 AM, Jeff Zhang <zjf...@gmail.com> wrote: > ClassloaderInterpreter could also be removed. > > > Jeff Zhang <zjf...@gmail.com>于2017年5月10日周三 下午3:39写道： > > > > > Hi moon > > > > Considering we use remote=true for interpreters now, and seems no user > > complain about that. So I think we could remove it completely. Agree with > > you that It could make code simpler, e.g. We don't need to check to use > > RemoteAngularObjectRegistry or AngularObjectRegistry. > > > > > > https://github.com/apache/zeppelin/blob/master/zeppelin- > server/src/main/java/org/apache/zeppelin/socket/NotebookServer.java#L1458 > > > > > > > > Jeff Zhang <zjf...@gmail.com>于2017年5月8日周一 下午6:15写道： > > > >> Although it can bring some benefits, but there are 2 disadvantages for > >> remote=false as I can think of > >> > >> 1. The interpreter log would mix with zeppelin server log. This may > cause > >> diagnosing difficult, markdown might be OK, but I am afraid it would be > a > >> problem for jdbc interpreter. > >> 2. Extra memory consumption. This might be a problem for jdbc > interpreter > >> when it gets large amount of data from database. > >> > >> > >> > >> moon soo Lee <m...@apache.org>于2017年5月8日周一 下午5:27写道： > >> > >>> The option is legacy and being used in few unit tests as far as i > >>> remember. > >>> > >>> I think we can either try completely remove this code (to keep code > base > >>> simple) or we can try re-introduce this feature (to optimize resource > >>> usage, less restriction on data sharing between interpreters). > >>> > >>> I think interpreters like markdown, jdbc will have no big problem with > >>> remote=false while Spark interpreter require separate JVM and > remote=true > >>> is required. > >>> > >>> remote=false will provide some chances to save some system resource > >>> because > >>> it does not run separate JVM process for interpreter. > >>> > >>> Also communication between interpreter (through ResourcePool) can be > much > >>> faster and have less restricted on object serialization. > >>> > >>> So remote=false option definitely provides some advantages. > >>> However, keeping code base for remote=false and remote=true introduces > >>> more > >>> work. > >>> > >>> What do you think? > >>> > >>> Thanks, > >>> moon > >>> > >>> On Mon, May 8, 2017 at 8:13 PM Jeff Zhang <zjf...@gmail.com> wrote: > >>> > >>> > I see all the interpreter setting set remote of interpreter option as > >>> true, > >>> > and didn't find any false case in interpreter-setting.json, does > anyone > >>> > know what is the use case of remote of interpreter option is false. > Is > >>> this > >>> > a legacy mode that should be removed ? > >>> > > >>> > > >>> > > >>> https://github.com/apache/zeppelin/blob/master/zeppelin- > zengine/src/main/java/org/apache/zeppelin/interpreter/ > InterpreterSettingManager.java#L183 > >>> > > >>> > >> > -- 이종열, Jongyoul Lee, 李宗烈 http://madeng.net
