Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to create core shouldn't raise an exception. #69

Open
jcoyne opened this issue Jul 14, 2016 · 5 comments
Open

Failure to create core shouldn't raise an exception. #69

jcoyne opened this issue Jul 14, 2016 · 5 comments

Comments

@jcoyne
Copy link
Collaborator

jcoyne commented Jul 14, 2016

Should we trap for this error in with_collection and just log it?

Failed to execute solr create:
ERROR:
Core 'blacklight-core' already exists!
Checked core existence using Core API command:
http://localhost:8983/solr/admin/cores?action=STATUS&core=blacklight-core
@afred
Copy link

afred commented Mar 1, 2017

I think the persist options is supposed to quiet this error.

However, I'm getting a related error, even when I set persist to true.

I checked my params at this point in the call stack, and they looked good: https://github.com/cbeer/solr_wrapper/blob/v0.21.0/lib/solr_wrapper/instance.rb#L152

One step deeper, I found that both calls to collection? and core? are returning false in SolrWrapper::Client.

In my case, I'm not in cloud mode, so the method of interest is SolrWrapper::Client#core?, and i found that value of JSON.parse(response.body)['status'] is coming back as {"my-production-core"=>{}} (where my-production-core is the name of my core).

So I'm wondering if that value in the response means the core is missing, or not?

Note that the first time of running solr_wrapper with the same options worked fine, and the core was created (I can see it on my filesystem).

@afred
Copy link

afred commented Mar 1, 2017

Followed up with a more detailed ticket in #92. Might supersede this one?

@calvinbutcher
Copy link

calvinbutcher commented Mar 30, 2017

I'm having problems with this in Hyrax 1.0.0.rc1. Running:

rake hydra:server

... results in the same error above:

ERROR: 
Core 'my-core' already exists!
Checked core existence using Core API command:
http://localhost:8983/solr/admin/cores?action=STATUS&core=my-core

Have tried setting persist: true but to no avail.

Is there a CLI workaround? I'm very new to all of this!

EDIT: have found a "rake solr:clean" resolves this. We're now looking at pointing the Hyrax gem to our own installations of Solr and Fedora4 so we don't need the "rake hydra:server" command...

@jrochkind
Copy link
Contributor

I believe this is getting in my way too. Anyone have any insight in the past two years?

@conorom
Copy link

conorom commented Jan 9, 2023

My insight is that I've been using solr_wrapper in dev for 6+ years and the existing core will get trashed at random times (regardless of machine speed, I'm on an M2 Mac right now) when the code that detects it does not work correctly.

To me the most egregious part isn't whether I get the (incorrect) exception message, as is the crux of this ticket, though that does indeed happen. It's that the existing core is successfully deleted before I can do anything about it, with the exception message mentioned here then being output as well, and Solr fails to start. Thought it will start the following time, only the core is gone.

So I would describe the problem more like #82 mentioned above, except with the core you need getting trashed into the bargain.

I think this affects me more than most, as I tend to hoard content in my development environment and, with the "double reindex of everything" required to get Hyrax/Samvera apps back working as expected, it has taken me the best part of a day to recreate my index in the past.

So what I do is go in and edit this line in my local gem, such that it always obeys the user "persist" request. Persist should trump "destroy and recreate", especially when the existence check cannot be trusted!

In other words I leave the rest of that line commented out the whole time for working on my main project:
return if options[:persist] # && create_options[:c] && client.exists?(create_options[:c])

And I live quite happily like that until I get a new machine or update this gem and get reminded of the issue.

Thoughts

  1. find a better core existence check. This page has a couple of newer answers that indicate the accepted solution (as used in this gem) is not reliable and/or has been superseded in newer versions of Solr
  2. in the interim (or anyway?) maybe rely on the user's input. If they said "persist" then assume something exists that is worth persisting. Bow out if they said "persist" and you can't find the core provided, given some network gremlins could always pop up. Assume users who know how to add/remove the persist option also know how to get the core deleted/recreated should they need to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants