Non-Obvious Things to Know When Coding in OpenSearch
summary
Covers concrete, actionable quirks: OpenSearch uses a binary transport protocol with explicit version checks when serializing action requests so clusters can mix versions, and action dispatch uses ActionListener callbacks instead of Java futures. Thread pools are numerous and size constrained so blocking causes pool exhaustion and assertions abort operations, e g the management pool caps at five threads and search threads default to floor(cores 3/2) + 1. Plugin class loaders are isolated causing jar errors and requiring shadow jars* or core shared libs to avoid class conflicts.
AI-written summary · about
chapters (12)
- 0:00Non-obvious OpenSearch coding
- 1:04OpenSearch architecture history
- 3:17Elasticsearch to OpenSearch
- 9:45Plugin model and dependency injection
- 19:14Sandboxing and plugin capabilities
- 22:31API actions and request handling
- 25:48Transport protocol serialization
- 26:33Asynchronous programming model
- 30:15OpenSearch thread pools
- 33:54Plugins and class loading isolation
- 38:13Concurrent OpenSearch development
- 39:18Q&A
related talks
39mDigging Into OpenSearch’s Memory: Lucene and JVM Garbage Collection Under the...
44mScaling OpenSearch at Uber: Operating Resilient, Fault-Tolerant, High-Performance Clus...
39mAccelerating Aggregations with Lucene-Aware Execution in OpenSearch
31mSharding 2.0: Unlocking Infinite Search Scalability in OpenSearch
22mSharding 2.0: Unlocking Infinite Search Scalability in OpenSearch
43mMulti-tenancy for all workloads
16mSponsored Keynote: OpenSearch at Atlassian Scale
46mUnconventional approaches to performance in Ozon's search engine