I would like to run a Bokeh Server application alongside another Tornado application (a Dask worker), sharing the same IOLoop. I’ve gone through the logic in bokeh/command/subcommands/serve.py and the bokeh Server object. From what I can tell there are two options:
Use the command infrastructure. This will parse arguments for me, set up application objects, handlers, etc. and plug them into a server and then start that server. Unfortunately this assumes that it’s going to start and control the IOLoop itself with no other applications active.
Build things manually. It appears that I want to create a bunch of applications with handlers, connect them up to a Server object and then finally call the start method of that object’s BokehTornado with start_loop=False. Unfortunately, there is a large amount of manual work here that is pretty error prone.
From a cursory glance it seems like there is a lot of very useful logic that is tied to using the command line interface. This makes sense given that it’s the common case, but it’s currently stopping me from using Bokeh server more widely throughout my application. Is there a clean way around this? If not then should I raise an issue?
On Sat, Nov 26, 2016 at 1:03 PM, Matthew Rocklin [email protected] wrote:
Use the command infrastructure. This will parse arguments for me, set up application objects, handlers, etc. and plug them into a server and then start that server. Unfortunately this assumes that it’s going to start and control the IOLoop itself with no other applications active.
Build things manually. It appears that I want to create a bunch of applications with handlers, connect them up to a Server object and then finally call the start method of that object’s BokehTornado with start_loop=False. Unfortunately, there is a large amount of manual work here that is pretty error prone.
From a cursory glance it seems like there is a lot of very useful logic that is tied to using the command line interface. This makes sense given that it’s the common case, but it’s currently stopping me from using Bokeh server more widely throughout my application. Is there a clean way around this? If not then should I raise an issue?
I would like to run a Bokeh Server application alongside another Tornado application (a Dask worker), sharing the same IOLoop. I’ve gone through the logic in bokeh/command/subcommands/serve.py and the bokeh Server object. From what I can tell there are two options:
–
You received this message because you are subscribed to a topic in the Google Groups “Bokeh Discussion - Public” group.
app = Application(handler) # or a list of handlers but usually just one
where a handler is a Handler subclass that modifies a document (passed into a .modify_document method by the Server when a session is initiated). There are currently handlers the e.g. use python code in a script, or a directory to modify documents. Possibly also of interest, there is a FunctionHandler that will accept an arbitrary function do the document modifications:
The function my_func could check sys.argv, or could be a closure that bundles a programmatically specified "argv" or whatever.
FunctionHandler is maintained under test but I'm not aware of any examples of its use (and I notice that some sub-packages like bokeh.application are accidentally missing from the reference guide).
Bryan
···
On Nov 27, 2016, at 8:57 AM, Matthew Rocklin <[email protected]> wrote:
Hi Sean,
Thanks! The bokeh.command.util.build_single_handler_applications was just the function I was looking for. Here is a minimal example:
from bokeh.server.server import Server
from bokeh.command.util import build_single_handler_applications
apps = build_single_handler_applications(['examples/app/crossfilter/'], {})
from tornado.ioloop import IOLoop
loop = IOLoop()
server = Server(apps, io_loop=loop)
server.start(start_loop=False)
assert server.io_loop is loop
assert server.io_loop._running
server.io_loop.start()