Class IndexPushDriver

java.lang.Object
ai.pipestream.module.pipelineprobe.opensearch.IndexPushDriver

@ApplicationScoped public class IndexPushDriver extends Object
Drives court-1000 PipeDocs at the opensearch-sink (OSS) production indexing path: PipeStepProcessorService.processData (unary). TODO: replace when opensearch-sink is demand-pull; engine should route to sink via DAG + claim-check.

This is the testing-sidecar "OpenSearch Index Tests" tab's push button. It bypasses the engine — engine is in flux and not under test here — and calls the same RPC the engine would invoke for an OSS pipeline step.

Why processData, not the experimental StreamDocuments

OSS exposes two services: OpenSearchIngestionService.StreamDocuments (bidi, marked experimental in OSS's own service-registration metadata — delegates to OSM's now-retired bidi StreamIndexDocuments) and the standard PipeStepProcessorService.processData, which is the production path: it iterates the IndexPlans bound to the request's pipeline-step config and XADDs an IndexRequest protobuf to pipestream:indexing:<plan_id> via OpenSearchIndexingPublisher. OSM's RedisIndexingConsumer (PR-1..PR-5) then drains those streams and bulks to OpenSearch. That's the path we want to stress.

Concurrency model

Unary RPC, blocking stub, virtual-thread pump. We spawn one VT per concurrency slot; each pulls from a Semaphore-throttled queue and does a blocking stub.processData(req). The semaphore is the natural backpressure here — every call is a real round-trip — so there's no deadlock risk from the old bidi-batch-flush quirk.

  • Constructor Details

    • IndexPushDriver

      public IndexPushDriver()
      CDI.
  • Method Details