Bidirectional callbacks instead of less effective callback/pooling?
And if the interpreter registers, there is no need for add
interpreter/remote application/remote port number? So this part of UI
is obsolete in 0.9?

If there is a local Zeppelin instance, the following in another process

        RemoteInterpreterServer interpreter=new
RemoteInterpreterServer("localhost",
             Constants.ZEPPELIN_INTERPRETER_DEFAULT_PORT, ":",
"groupId", false);

throws "connection refused". Possibly because it does not work in 0.9
as you said.

On Tue, Nov 5, 2019 at 2:24 PM Jeff Zhang <zjf...@gmail.com> wrote:
>
> callback host is the Zeppelin Server host, RemoteInterpreterServer needs to 
> know where is the Zeppelin Server and register to it, in that way they can 
> establish bi-directional communication between Zeppelin Server and 
> RemoteInterpreterServer.
>
> Artur Rataj <arturra...@gmail.com> 于2019年11月5日周二 下午6:08写道:
>>
>> What is this callback host in RemoteInterpreterServer? Does it specify
>> a concrete instance of Zeppelin? If yes, why? I would think that the
>> interpreter waits on a port and creates its new instances for any
>> Zeppelin instance that connects.
>>
>> On Tue, Nov 5, 2019 at 8:58 AM Artur Rataj <arturra...@gmail.com> wrote:
>> >
>> > So I will write a local interpreter for now. I want to use Zeppelin as an 
>> > UI of an app, but I do not want to put an app into Zeppelin sources, a 
>> > remote interpreter would be very handy here.
>> >
>> >
>> >
>> >
>> > On Tue, Nov 5, 2019 at 2:30 AM Jeff Zhang <zjf...@gmail.com> wrote:
>> >>
>> >> I think connecting to remote interpreter is broken in 0.9, because we 
>> >> introduce bi-directional communication channel in 0.9.
>> >>
>> >> https://issues.apache.org/jira/browse/ZEPPELIN-2035
>> >>
>> >>
>> >> Artur Rataj <arturra...@gmail.com> 于2019年11月5日周二 上午12:42写道:
>> >>>
>> >>> Please, give me some hints...
>> >>>
>> >>> On Mon, Nov 4, 2019 at 5:39 PM Artur Rataj <arturra...@gmail.com> wrote:
>> >>> >
>> >>> > To sum this up,
>> >>> > https://zeppelin.apache.org/docs/0.7.0/manual/interpreters.html#connecting-to-the-existing-remote-interpreter
>> >>> > says
>> >>> >
>> >>> > RemoteInterpreterServer interpreter=new RemoteInterpreterServer(3678);
>> >>> > // Here, 3678 is the port on which interpreter will listen.
>> >>> >
>> >>> > This constructor, however, does not exist any more. What exists is:
>> >>> >
>> >>> >   public RemoteInterpreterServer(String intpEventServerHost,
>> >>> >                                  int intpEventServerPort,
>> >>> >                                  String portRange,
>> >>> >                                  String interpreterGroupId,
>> >>> >                                  boolean isTest)
>> >>> > which requires intpEventServerHost!=null && isTest=false for
>> >>> > createInterpreter() to work. This in turn attempts to connect to
>> >>> > intpEventServerHost:intpEventServerPort. The latter looks like
>> >>> > "interpreter event server host". Possibly it is about the web server,
>> >>> > so I put localhost:8080 there.
>> >>> >
>> >>> > So possibly, now it is the interpreter which connects to Zeppelin, and
>> >>> > not the opposite? But then why "connect to remote process" still
>> >>> > requires a port? I need to specify the port somewhere. Be it,
>> >>> > "portRange" has something in common? Not, putting a port there makes
>> >>> > IndexOutOfBoundException elsewhere. So port:port possibly if it is
>> >>> > called a range? This time, createInterpreter works, but even after
>> >>> > interpreter restart, Zeppelin shows "Interpreter process is not
>> >>> > running: null".
>> >>> >
>> >>> > I appreciate your effort, I know that Zeppelin has in general good
>> >>> > docs, and that it is just an experimental snapshot, but I give up. It
>> >>> > is about a *remote* interpreter anyway, and I do not want to become a
>> >>> > Zeppelin insider because of it, would read some rudimentary docs
>> >>> > instead.
>> >>> >
>> >>> >
>> >>> > On Mon, Nov 4, 2019 at 4:52 PM Artur Rataj <arturra...@gmail.com> 
>> >>> > wrote:
>> >>> > >
>> >>> > > So I attempted to write a rudimentary remote interpreter anyway,
>> >>> > > despite that isTest needs to be true for the remote server 
>> >>> > > constructor
>> >>> > > to work. The effect is, the server's method createInterpreter throws
>> >>> > > NullPointerException, as it calls intpEventClient, which in turn is
>> >>> > > initialised only if isTest is false.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > On Mon, Nov 4, 2019 at 4:06 PM Artur Rataj <arturra...@gmail.com> 
>> >>> > > wrote:
>> >>> > > >
>> >>> > > > Yes, I can do that, but I would want to connect to my interpreter 
>> >>> > > > via
>> >>> > > > any Zeppelin instance, not only via one customised, with an 
>> >>> > > > additional
>> >>> > > > interpreter added to its sources at compile time. This is why I 
>> >>> > > > wanted
>> >>> > > > to use a remote interpreter, i.e. one in an independent 
>> >>> > > > application.
>> >>> > > >
>> >>> > > > This constructor:
>> >>> > > >
>> >>> > > >         RemoteInterpreterServer interpreter=new
>> >>> > > > RemoteInterpreterServer("localhost",
>> >>> > > >             
>> >>> > > > RemoteInterpreterUtils.findRandomAvailablePortOnAllLocalInterfaces(),
>> >>> > > > ":", "groupId", true);
>> >>> > > >
>> >>> > > > works only with isTest=true, which I guess is for ... testing only.
>> >>> > > > But I do not know, there are no docs.
>> >>> > > >
>> >>> > > > If the remote interpreter does not work, I will modify some simple
>> >>> > > > interpreter to support a remote interpreter. I guess that it would
>> >>> > > > work, but it seems somewhat nonsensical to implement a 
>> >>> > > > functionality
>> >>> > > > which in theory is already provided by Zeppelin.
>> >>> > > >
>> >>> > > >
>> >>> > > > On Mon, Nov 4, 2019 at 3:55 PM Jeff Zhang <zjf...@gmail.com> wrote:
>> >>> > > > >
>> >>> > > > > The most simplest interpreter might be shell interpreter. You 
>> >>> > > > > can create a simple interpreter module like sh module, and 
>> >>> > > > > extend abstract class Interpreter.
>> >>> > > > >
>> >>> > > > > Refer
>> >>> > > > > http://zeppelin.apache.org/docs/0.8.2/development/writing_zeppelin_interpreter.html#make-your-own-interpreter
>> >>> > > > >  
>> >>> > > > > https://github.com/apache/zeppelin/blob/master/shell/src/main/java/org/apache/zeppelin/shell/ShellInterpreter.java
>> >>> > > > >
>> >>> > > > >
>> >>> > > > > Artur Rataj <arturra...@gmail.com> 于2019年11月4日周一 下午10:44写道:
>> >>> > > > >>
>> >>> > > > >> I would need any way of writing a remote interpreter for 
>> >>> > > > >> Zeppelin 0.9.
>> >>> > > > >> It would be useful to have some docs, an example or whatever 
>> >>> > > > >> which
>> >>> > > > >> describes RemoteInterpreterServer in 0.9. No API docs in the 
>> >>> > > > >> sources,
>> >>> > > > >> searching in turn for an actual usage of 
>> >>> > > > >> RemoteInterpreterServer on
>> >>> > > > >> the web shows some no-more-working test in 0.9.
>> >>> > > > >>
>> >>> > > > >> If I connect via Zeppelin to (new RemoteInterpreterServer(null,
>> >>> > > > >> SOME_PORT, "some-name", null)).start() and connect via add
>> >>> > > > >> interpterer/connect to existing process on the Zeppelin side, I 
>> >>> > > > >> get it
>> >>> > > > >> causes java.lang.RuntimeException:
>> >>> > > > >> org.apache.thrift.TApplicationException: Internal error 
>> >>> > > > >> processing
>> >>> > > > >> createInterpreter. If I replace null with any name like 
>> >>> > > > >> localhost, i
>> >>> > > > >> get "connection refused" on the interpreter side. By the way, 
>> >>> > > > >> checking
>> >>> > > > >> "connect to existing process" still makes it mandatory to 
>> >>> > > > >> specify
>> >>> > > > >> "interpreter group".
>> >>> > > > >>
>> >>> > > > >> Could you give me some basic hints on making a connection to a 
>> >>> > > > >> simple
>> >>> > > > >> remote interpreter which consumes paragraph contents and 
>> >>> > > > >> produces
>> >>> > > > >> %html?
>> >>> > > > >
>> >>> > > > >
>> >>> > > > >
>> >>> > > > > --
>> >>> > > > > Best Regards
>> >>> > > > >
>> >>> > > > > Jeff Zhang
>> >>
>> >>
>> >>
>> >> --
>> >> Best Regards
>> >>
>> >> Jeff Zhang
>
>
>
> --
> Best Regards
>
> Jeff Zhang

Reply via email to