Shawn,
On 5/17/23 21:45, Shawn Heisey wrote:
On 5/17/23 11:40, Christopher Schultz wrote:
Thanks for your replies and I apologize for the noise. I'll pick this
thread back up if for some reason I am able to reproduce the issue.
I can't tell you how many times I have done this. Ask for help, and
while working diligently to document the problem beyond my initial
description, I either can't reproduce it or the solution becomes
extremely obvious. I consider that to be a learning experience.
:)
I usually discover most problems and fix them during the "asking for
help" drafting process, and end up never sending the message. In this
case, I mist have missed something.
Speaking of the lag-between-insert-and-searchability, is there any
information Solr is able to provide regarding a core's freshness?
<snip>
// lastModified=Mon Mar 06 14:58:22 EST
2023,sizeInBytes=56606,size=55.28 KB}}}
Presumably, lastModified gives me the timestamp the last document was
added. What about when the index was opened for searching?
Yes, that is exactly what I was going to point you at. The info comes
from Lucene and is the last time ANY change was made to the index ...
add, update, delete, etc.
Great. I'm already reporting this to the admin user, so I now just have
to add...
As for when the searcher was opened, that is slightly complicated if
you're in cloud mode, but it's really easy if you're in standalone mode,
because the core name will be known in advance. In cloud mode you won't
always know the core name to look for just based on the collection name.
As it happens, we are using standalone cores, so I get to choose the
"easy path" for now. ;)
Here's how you would parse it with jq ... I am pretty sure there is a
way to do it with SolrJ too:
https://www.dropbox.com/s/fs01ogmtqwsj3yd/using_jq_to_parse_metrics_for_searcher_open_time.png?dl=0
So... call /solr/admin/metrics and look through the stuff. I'll see if
there is a convenient SolrJ mechanism for that.
I will see if I can hack together some SolrJ code to duplicate that. Are
you in cloud mode or standalone? If cloud mode, which SolrClient
implementation are you using? I will use SolrJ 9.2.1 to work on it ...
hopefully it's not horrible to translate to a version 7 SolrJ.
I didn't know there were multiple SolrJ implementations. I'm using the
client library directly from the Solr project with a version number of
7.7.3. It looks like I have been running against an 8.1.1 server in my
development environment while we have 7.7.3 in both staging and
production. My goal was to upgrade to Solr 8.latest in the very near
future, but I wanted to have all this code in-place to allow for
completely automated schema updates and index re-build before doing
that, because I understand that moving between major versions basically
requires a complete index re-build. I'd rather have a completely
point-and-click admin-initiated process for that than a manual "type
these 40 commands" process to make the migration super duper easy.
So, long story short, if there is a specific reason that upgrading to
8.latest will make this easier, consider it done.
Thanks,
-chris
