Acquia Search for Search API is incompatible with Search API Solr search 7.x-1.0-rc4

Thanks for bringing this up. For the time being I will put a note on the project page highlighting the incompatibility and we will work to resolve the issue.

As mentioned in the OP, the API change in Search API Solr search that resulted in the incompatibility is highlighted at #1846254: Remove the SolrPhpClient dependency.

I tried the last search_api_solr + search_api_acquia and when indexing I have this error :

error ResponseText: Exception: SolrPhpClient library not found! Please follow the instructions in search_api_solr/INSTALL.txt for installing the Solr search module. in SearchApiAcquiaSearchService->connect() (line 19 of .../livedev/docroot/sites/all/modules/search_api_acquia/includes/SearchApiAcquiaSearchService.php).

For the moment, it looks like using search_api_solr-7.x-1.0-rc3 is working

FYI search_api_solr 7.x-1.0 is out.

It would be great to get an idea if this is something that is in progress, if there is a timeline, etc.

Also, I am having issues getting rc3 working. Are there specific versions of search_api and search_api_solr that we need to use?

Thanks

I'm using search API Acquia beta3, search api solr rc3 and an out of date dev version of search API and it is working.
The search API version shouldn't really matter as long as it is compatible with search api solr rc3.

I had some problems getting mine set up too.

One problems was that the search setup on the Acquia end was not properly configured.
I submitted a support request and they sorted that out.

Then there was the confusing options on the select field on the Acquia site where you choose what search module you are using.

Off the top of my head I can't remember what the options were but at that time I think there was search api solr rc2 and search api solr rc3+ options.

I am running rc3 but had to select the rc2 option for things to work properly.

When I selected rc3 I could get some of my indexes to work but not others.

I mentioned to support their docs needed updating but I'm not sure if they have been yet.

@rooby Question for you. You say "The search API version shouldn't really matter as long as it is compatible with search api solr rc3". Do you know what was the latest Search API version that works with Search Api Solr rc3? Apparently the version I'm using doesn't work, because in Acquia Network when I go to the Search config page, it's blank with no ability to select Search API.

We're successfully using Search API Solr rc3 with Search API 7.x-1.5. I had to roll back all three modules (Search API, Solr Search, Acquia search) at least one or two versions to get things working again.

Even though I'm not an active user and haven't yet really worked with it, I tried to come up with a patch for this. It's of course bad if users of such a popular service are stuck with an older version, especially now that Search API Solr Search is finally stable.

Patch attached, please test/review!
(As said, I'm no Acquia Search user, so I only fixed what looked wrong.)

The patch in #9 works! At first, after applying the patch and updating my modules, the search pages were broken (errors etc). Simply clearing the cache (drush cc all) brought everything back.

Amazing work, thank you!

EDIT: Others in the issue, please give the patch a review with the latest versions of all modules (I used -dev of everything).

@tvilms

This may be an issue with Acquia's automatic provisioning of Solr not working. See http://forums.network.acquia-sites.com/acquia-products-and-services/acqu...

I tried and tried to get it working and then just filed a ticket with Acquia. They said

"It looks like Solr wasn't automatically provisioned for your account, so I was able to manually enable it for you. In order for your site to connect, you'll need to do the following:

Log into your site as the admin user.
Go to /admin/reports/status
Under "Acquia Network subscription status", click on "manually refresh the subscription status"
Once you've done this, everything should connect and your site should start sending indexing data to Solr."

This worked for me

I tried to apply the patch to dev but 1 out of 2 hunks FAILED on includes/SearchApiAcquiaSearchService.php
Looks like dev was updated the day after the patch was posted.

Works with:
entity search_api search_api_solr search_api_acquia --dev
search_api_acquia-7.x-1.0-beta3

I was switching from a site that was working with search_api_solr-7.x-1.0-rc3

Tasks:
1. Ran drush updb, drush cc all, drush cron
2. Also disabled and enabled index and server.
3. There was also an issue with the solr url which was fixed by editing and resaving.

Also seems to work with release versions of the dependent modules

The attached patch should work with the latest dev version (I hope).

Seems to be working.
I was able to index 13,970 nodes in one batch and retrieve search results.

Entity API 7.x-1.1
Search API 7.x-1.7
Solr search 7.x-1.0
Acquia Search for Search API 7.x-1.0-beta3+1-dev (with patch from #14)

Thanks!

Reviewing! Thanks a ton!

@@ -11,25 +11,256 @@
+   *  The solr url beng requested - passed by reference and may be altered.

being requested

I'll commit this! Great work

We need to be really careful about an upgrade path. When I tested this is caused fatal errors, and it was very difficult to get the site back in a consistent state via the UI.

Are we able to test this somehow?

Can we get a scenario written out and see what needs to change? From conversations with Chris Pliakas the server entities themselves save the class and probably need an update function so that they do not try to instantiate the old class / solrphpclient.

After getting this working it has since stopped working.
Has the patch been applied to dev?
Is there an option available for the Solr config that should work?

We need to upgrade so we can use https://drupal.org/project/issues/search_api_location which requires RC4 or higher.

Thanks

I have been working with chrowe on getting this working with the newest version of Search API Solr. I was able to get a full setup using Acquia's Solr and Search API that also supported Search API location working locally. However, when this codebase was pushed to our dev site, which is running on Acquia Cloud it broke, unable to contact server and 404 errors on searches. What is strange is on the working instance(local) our search url is showing as http://useast1-c1.acquia-search.com:80/solr/DJQU-36*** and on the broken sites(Acquia Network) it is showing as http://search.acquia.com:80/solr/DJQU-36***. I am guessing this is the root cause of our issues, as the following errors are also being thrown.

- Notice: Undefined variable: search_host in SearchApiAcquiaSearchService->configurationForm() (line 118 of /var/www/chapa-mahr/docroot/sites/all/modules/patched/search_api_acquia/includes/SearchApiAcquiaSearchService.php).
- Notice: Undefined variable: identifier in SearchApiAcquiaSearchService->configurationForm() (line 120 of /var/www/chapa-mahr/docroot/sites/all/modules/patched/search_api_acquia/includes/SearchApiAcquiaSearchService.php).

I am going to do some more review of the Search API Acquia codebase and will keep this ticket updated. What is really confusing is that the same codebase works on my local but fails on dev. Below is a quick breakdown of the modules we are running.

Acquia Search for Search API 7.x-1.0-beta3+1-dev (patched with Drunken Monkeys patch from #14)
Search API 7.x-1.7
Solr search 7.x-1.2

Through some new work today, I have tracked down the issue to a bug that in some situations forces the default search.acquia.com to be used no matter what. Additionally, the settings form to allow you to override your search settings does not correctly save. I will be looking to fix both of these issues and will submit a patch when complete.

That's great news, thanks! Please keep us posted.

I've put a patch in #2087141: acquia_search_host takes precedence over $subscription['heartbeat_data']['search_service_colony'] that I believe may solve the issue with server instances using search.acquia.com incorrectly.

I started from scratch to understand what the flow was. Similar to previous patch the httpTransport is gone and I added some other nifty changes which I will highlight in next comment

@@ -5,24 +5,29 @@
+  protected function connect() {
+    parent::connect();
+    // allow the connection to override the derived key
+    if (isset($this->options['derived_key'])) {
+      $this->solr->setDerivedKey($options['derived_key']);

This takes the original connect method and adds a possibility to override the derived key. This is better than re-implementing the connect method

@@ -36,11 +41,11 @@ class SearchApiAcquiaSearchService extends SearchApiSolrService {
+    $url = $options['scheme'] . '://' . $options['host'] . ':' . $options['port'] . $options['path'];

The scheme is now strictly followed

@@ -36,11 +41,11 @@ class SearchApiAcquiaSearchService extends SearchApiSolrService {
+    $output .= $url;

Url is no longer clickable, this was unnecessary and confusing

@@ -74,14 +79,11 @@ class SearchApiAcquiaSearchService extends SearchApiSolrService {
-    $search_port = variable_get('acquia_search_port', '80');

the ports are now chosen based on the http/https protocol. No need for users to try and define their own ports if they use Acquia Search

Committed, let's track the other issues in other threads.