-
Notifications
You must be signed in to change notification settings - Fork 14
/
TODO
52 lines (41 loc) · 2.57 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Known bugs:
1. Shim does not work with plugins that require client load of plugin.so.
The best example of this is timeseries. I'm not sure how to write a SciDB
client that can use the pluginManager correctly...
Things to do soon:
* Add a signal handler to clean up temporary files and disconnect clients
on SIGTERM before exiting.
* finish the control API, which is partially disabled until authentication
is added.
* SciDB port selection from control API (i.e., SciDB db selection)
* Add authentication, at least for the control API.
* https (available already in mongoose, need to hook up)
* Maybe this can be used to identify the present DB when we know its name?:
# ps axu | grep SciDB | grep dbname | head -n 1 | sed -e s/.*dbname=// | cut -d ' ' -f 1
* Improve performance of returned results...
Shim employs a really simple scheme to move results from SciDB to web clients.
Shim asks SciDB to save the results of a query to a file. Then, it returns the
contents of the output file to the client. This seems pretty dumb. In
particular, the client has to wait for the entire query to finish right now
before beginning to download the result.
OK, so why not at least use a pipe instead of a file? Or an even fancier SciDB
client interface that streams results to the client via HTTP?
I made the present choice because I want to try to prevent web clients from
making SciDB hang. Web clients enjoy freedom to come and go and might
realistically initiate a query, but then go away without consuming the result.
Writing the result to a file on the server side means that there is always a
final consumer for the query, even if the web client doesn't ever claim it.
SciDB writes the output and moves on.
So, this choice is a practical one to keep SciDB available in the event of
a flaky web client query end point. This scheme, while extremely trivially
simple, works in practice reasonably well.
But, there are still things we can do that preserve SciDB isolation from flaky
web clients and allow us to begin streaming results to the client before the
query finishes. For example, we might have shim set up an output pipe in
addition to the SciDB output file for each client. Shim could then pipe the
output file to the output pipe, and connect the output stream to the web client
to the output pipe instead of the file. That is, set up a file-buffered client
output pipe. That way SciDB writes to a file safely on the server, yet shim
could make available partial query output immediately to the client via the
read_lines or read_bytes API calls.
Other approaches could work too. Anyway, this is a TODO item.