Re: What is the user case for remote of interpreter option is false

2017-05-16 Thread Jeff Zhang
Sure Jongyoul, go ahead. Jongyoul Lee 于2017年5月13日周六 上午10:19写道: > 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,

Re: What is the user case for remote of interpreter option is false

2017-05-13 Thread Jongyoul Lee
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 wrote: > ClassloaderInterpreter could also be

Re: What is the user case for remote of interpreter option is false

2017-05-10 Thread Jeff Zhang
ClassloaderInterpreter could also be removed. Jeff Zhang 于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

Re: What is the user case for remote of interpreter option is false

2017-05-10 Thread Jeff Zhang
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.

Re: What is the user case for remote of interpreter option is false

2017-05-08 Thread Jeff Zhang
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

Re: What is the user case for remote of interpreter option is false

2017-05-08 Thread moon soo Lee
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