eZ Community » Forums » Extensions » eZ Find » eZ Find Multi-core Shards
expandshrink

eZ Find Multi-core Shards

eZ Find Multi-core Shards

Friday 11 May 2012 10:00:06 pm - 2 replies

We are currently trying to transition our sites to use eZ Find multicore to reduce the load on our 1 solr install. We are using search shards to search the cores when we need content from a different core. This all works great with 1 glaring exception. We have store all attributes set to true and as_objects set to false so that we can get all content from Solr. When the search is run through the shard, none of the binary is returned properly, so the data_map is filled with null values. When I look at the binary that is supposed to be returned to be unserialized by eZ Find it looks something like this: [B:[B@294de1c8
When I look at the binary directly in the admin or when I search on the core that houses the index everything works as expected, it is only when searching through shards. There is always a [B:[B@ preceding a much shorter string than the encoded binary. Any idea what is causing this to happen?? Is this a bug in eZ Find or Solr? Related to this topic on stack overflow. 

Wednesday 13 May 2015 7:16:55 pm

Hi Tyler,

Just wondering, did you manage to fix the problem you mention in this thread? If so, may you please give some clues on how?

I have a similar problem, trying to search with eZ Find from site A, but want to get search results from both site A and site B.

Site A and Site B are totally separate eZ Publish installations, 2013.11, but resides on the same server.

By using multicore (found out how on your blog. Thanks!) and shards, I can now get results from both site A and site B. But the results from site B only holds the name of the object, no other relevant data.

I have tried to switch to as_objects= false in the fetch, and indexing with EnableAttributeStorage=true, but the data_map holds only NULLs, just as you mention above.

So I wonder where the verbose data from the Solr index is?

Any ideas are welcome!

Cheers,

Nicklas

Tuesday 19 May 2015 8:17:50 pm

Hi Nichlas,

We were able to get past this issue by patching the version of Solr that shipped with eZ Find. At the time this post was originally published, we were using Solr 3.6 which is/was the cause of this bug. This bug has nothing to do with eZ Publish or eZ Find unfortunately. In order to fix I had to download the source and patch Solr 3.6 manually myself. I couldn't go to Solr 4 at the time because eZ Find's Solr plugin that allows editors to manually elevate content via the admin is/was incompatible with Solr 4 (also Solr 4 was still alpha). The patch attached to this JIRA ticket can be applied to Solr 3.6 pretty easily if upgrading eZ Find is not an option, though upgrading eZ Find would be the recommended course.

Best of luck to you,

Tyler

Modified on Tuesday 19 May 2015 8:19:12 pm by Tyler Harms

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from