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,
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
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
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.
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
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