UBI goes distrib

[mkhludnev]

This what I understand about distributed Solr.

[mkhludnev]

@epugh I noticed that UBI comp yields a kind of stream into ubi_queries. Should we create such collection before issuing queries?

[mkhludnev]

UBIComponentDistrQueriesTest fails with

12544 WARN  (qtp1249319859-57) [n: c: s: r: x: t:] o.e.j.s.HttpChannel /solr/collection1_shard2_replica_n1/select
          => java.lang.AssertionError
	at org.apache.solr.handler.component.RealTimeGetComponent.addDocListToResponse(RealTimeGetComponent.java:1180)
java.lang.AssertionError: null
	at org.apache.solr.handler.component.RealTimeGetComponent.addDocListToResponse(RealTimeGetComponent.java:1180) ~[main/:?]

and it doesn't seem specific to UBI. I'm stuck. Don't know how to get through it.

okay. I've figured it out https://github.com/apache/solr/pull/2452/files#r1875035115

[mkhludnev]

@epugh do you have an idea how to wait till update stream have landed to ubi_queries?

[epugh]

hummm.... so, I think that in the UBIComponent when we call getTuples, there is a chance that it waits till we finish that step? You are using the configset that wraps the update() with an explicit commit(), which you woudn't do in a prod setup, just so we can see the new docs:

https://github.com/apache/solr/pull/2452/files#diff-cdf9aaba8c6979df48bf217e3f81fa7be42af135abd382c4fba28d79778b4945

I looked at some tests like https://github.com/apache/solr/blob/main/solr/solrj-streaming/src/test/org/apache/solr/client/solrj/io/stream/StreamDecoratorTest.java#L364 and they are why I believe it is actually a synchornous process, not a back ground process...

[epugh]

Would it be useful to add you to the epugh/solr repo?

[mkhludnev]

Would it be useful to add you to the epugh/solr repo?

nope. I can push into apache#2452 as a maintainer.
Just merge this once please, since it's a kind of ground level for distributed UBI.
And then I'll continue in apache#2452 if you don't mind.

[epugh]

Merged! and please do continue! this is super great to have a collaborator!