It seems like solarium OOTB sets up a default solr instance on localhost:8983 and when you come to add a server in search_api it bails with;
Solarium\Exception\InvalidArgumentException: An endpoint must have a unique key in Solarium\Core\Client\Client->addEndpoint() (line 300 of /xxx/modules/contrib/search_api_solr/vendor/solarium/solarium/library/Solarium/Core/Client/Client.php).
Evidence in the code;
vendor/solarium/solarium/library/Solarium/Core/Client/Client.php
/**
* Default options
*
* @var array
*/
protected $options = array(
'adapter' => 'Solarium\Core\Client\Adapter\Curl',
'endpoint' => array(
'localhost' => array()
)
);
vendor/solarium/solarium/library/Solarium/Core/Client/Endpoint.php
/**
* Default options
*
* The defaults match a standard Solr example instance as distributed by
* the Apache Lucene Solr project.
*
* @var array
*/
protected $options = array(
'scheme' => 'http',
'host' => '127.0.0.1',
'port' => 8983,
'path' => '/solr',
'core' => null,
'timeout' => 5,
);
The endpoint check;
vendor/solarium/solarium/library/Solarium/Core/Client/Client.php
if (array_key_exists($key, $this->endpoints) && $this->endpoints[$key] !== $endpoint) {
throw new InvalidArgumentException('An endpoint must have a unique key');
}
Not quite sure what the solution should be?.. I mean, we could trap someone trying to enter 'localhost' as their endpoint machine name and tell them that they can't but it'd be confusing as the list of servers would be blank.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2643788-09.patch | 806 bytes | jhedstrom |
Comments
Comment #2
pobster commentedComment #3
berdirI'm using localhost and it works just fine for me, not why you get an error? Maybe a new solarium version?
Comment #4
pobster commentedAll I did was to grab the latest dev version of search_api_solr and run
composer updatein the module folder. Nothing else? My Drupal 8 install is a stock 8.0.1 for development, but it's completely clean ~ I haven't even started development yet.Comment #5
Anonymous (not verified) commentedfyi, cref also
"on action exec, Error: Call to undefined method Drupal\search_api\Query\Query::getFilter()"
https://www.drupal.org/node/2644308
Comment #6
matthewmessmer commentedI was able to get it working as long as the machine name of the server was something other than 'localhost'. After I changed the machine name to 'localhost2' I could save without getting the error.
Comment #7
pobster commentedErm that's the point? It shouldn't do that :o) It should allow you to override the default set in Solarium or at the very least, tell you that you can't use "localhost" rather than fail hard.
Comment #8
berdirAh, I get it now, I thought you meant when using localhost as hostname.
Sure, that shouldn't happen.
Comment #9
jhedstromI ran into this and spent a bit of time trying to figure our what was going on until I just renamed the machine name of the server to something other than
localhost.Digging in a bit, I think this error can be avoided by preventing Solarium from initializing the default endpoint.
Comment #10
pobster commentedThat's neat, yeah I like it as a solution. I'm a +1 for this.
Comment #11
berdirWorks for me too.
We could change our tests to create a server with the id localhost but not sure that's worth it?
Comment #12
geerlingguy commentedAnother +1/RTBC here. For local dev, I usually use 'localhost' as the key.
Comment #13
pobster commented@Berdir I agree, I doubt there's much point in testing for this particular scenario? It's more an implementation detail than a bug which needs to be fixed.
Comment #14
mkalkbrennerThanks for that patch. But I think that this isn't an issue anymore since #2677760: Destinguish between Solr server and deployed cores and improve version auto-detection was committed, or to be more concrete
https://www.drupal.org/commitlog/commit/16802/f6fd74c92c8ca459f748e86a7d...
Before that patch the server ID was used as the name for the endpoint. Now we use two endpoints named 'server' and 'core'. As a side effect they don't conflict with 'localhost' anymore.
Can someone verify this please?
Comment #15
mkalkbrennerPlease reopen the issue if it still occurs.
Comment #16
pobster commentedOop, apologies ~ missed your first message. Yes I'll verify over the weekend but from first impressions it looks fine, if we no longer have to specify the endpoints ourselves and they're hardcoded then there can be no conflict. Thank you.
Comment #18
mkalkbrenner