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.

CommentFileSizeAuthor
#9 2643788-09.patch806 bytesjhedstrom
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pobster created an issue. See original summary.

pobster’s picture

Issue summary: View changes
Berdir’s picture

I'm using localhost and it works just fine for me, not why you get an error? Maybe a new solarium version?

pobster’s picture

All I did was to grab the latest dev version of search_api_solr and run composer update in 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.

Anonymous’s picture

fyi, cref also

"on action exec, Error: Call to undefined method Drupal\search_api\Query\Query::getFilter()"
https://www.drupal.org/node/2644308

matthewmessmer’s picture

I 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.

pobster’s picture

Erm 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.

Berdir’s picture

Ah, I get it now, I thought you meant when using localhost as hostname.

Sure, that shouldn't happen.

jhedstrom’s picture

Status: Active » Needs review
FileSize
806 bytes

I 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.

pobster’s picture

That's neat, yeah I like it as a solution. I'm a +1 for this.

Berdir’s picture

Status: Needs review » Reviewed & tested by the community

Works for me too.

We could change our tests to create a server with the id localhost but not sure that's worth it?

geerlingguy’s picture

Another +1/RTBC here. For local dev, I usually use 'localhost' as the key.

pobster’s picture

@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.

mkalkbrenner’s picture

Status: Reviewed & tested by the community » Needs review

Thanks 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?

mkalkbrenner’s picture

Status: Needs review » Fixed

Please reopen the issue if it still occurs.

pobster’s picture

Oop, 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

mkalkbrenner’s picture