Will have to be split into multiple tickets.
To do:
* Check with async experts (Clément?) that implementing our own publisher/subscriber is not a bad idea (not the reactive map/filter/etc. bits, just the raw publisher/subscriber)
* Implement/expose result scrolling as a {{createPublisher}} operation so that users can wrap that with their reactive library.
* Implement mass indexing with a publisher/subscriber pattern
* Size of workset queues: see HSEARCH -3575.
* Make queueing of works throw an exception instead of blocking when the queue is full. Maybe allow the client to choose between failing and blocking? It might make sense to block if the client will block anyway.
* Implement cancellation of works simply by allowing the user to call {{cancel()}} on the returned future. In the work consumer thread, if the future is complete with a CancellationException, we'll just ignore the corresponding work. If it's not, we'll send the work to the REST client and add an exception handler ({{.exceptionally(...)}} to the user-returned future : if the future is completed with a CancellationException, we'll cancel the HTTP request (is it possible?). see HSEARCH-3590
|
|
