Every service starts bleve goroutines

[wkloucek]

Describe the bug

Start a service (except search). Have a look at the goroutines.

Steps to reproduce

Steps to reproduce the behavior:

1. run a single oCIS service with pprof enabled
2. open the /debug/pprof endpoint and look at the goroutines

Expected behavior

See no bleve goroutines

Actual behavior

See bleve goroutines

4 @ 0x43e376 0x44e29c 0x1ecbf0f 0x4702e1
#	0x1ecbf0e	github.com/blevesearch/bleve_index_api.AnalysisWorker+0x8e	github.com/blevesearch/bleve_index_api@v1.0.3/analysis.go:46

Additional context

Bleve analyzer use an init() function to register themselves (eg. https://github.com/blevesearch/bleve/blob/20e6eb5564e5c94478c865c6e03944882c7a886c/analysis/analyzer/keyword/keyword.go#L36-L38)

We import it through our config / command setup in the single binary, so it always started. Even if we just start one service (not using bleve).

[jvillafanez]

This seems a "won't fix", at least from OCIS' side.
As far as I know, go doesn't support conditional import neither dynamic loading. The only viable option I think we have is to use conditional compiling with build tags, but we'd need to generate 2 different executables: one with the import and another without it. This sounds inconvenient for the user, and it will add a lot of maintenance burden on our side.

I guess they need to fix it on their side first.

[kobergj]

Maybe we are just building it wrong? If we would build services individually we would not have this problem. Also binary sizes would be much smaller. We would just need to make the single binary optionally (or get rid of it at all...)

[wkloucek]

Also binary sizes would be much smaller. We would just need to make the single binary optionally (or get rid of it at all...)

we have been there: #6819