cancel
Showing results for 
Search instead for 
Did you mean: 

Alfresco Share + SOLR people search doubts

sujaypillai
Confirmed Champ
Confirmed Champ
Hello All,

I have configured Alfresco Share to use SOLR for search. During configuration what I found is that it uses mainly 2 cores -
    workspace for store workspace://SpacesStore
    archive for store archive://SpacesStore
Does this mean that the people search wouldn't work with SOLR as it resides in user://alfrescoUserStore ?

When I do a people search by navigating to the search form by clicking People on top navigation bar, does it go for a LUCENE search/SOLR search?


Any comments on above points will be appreciated?


Thanks,
13 REPLIES 13

afaust
Legendary Innovator
Legendary Innovator
Hello,

people do reside in workspace://SpacesStore, so SOLR can be used here. user://UserStore only contains Alfresco-local userdata and is not relevant for anything other than authentication.

The people search will usually use SOLR/Lucene, but as far as I know, there is a special variant in there that uses a simplified search via the database in a special use case scenario.

Regards
Axel

sujaypillai
Confirmed Champ
Confirmed Champ
Hello Axel,

Thanks for your inputs.

I just shifted from Lucene to SOLR and find a significant change in the response time to the results returned by people-finder webscript. Do you have any idea why this should be taking long for the results to be returned?

Any configurations changes that needs to be done for this?

there is a special variant in there that uses a simplified search via the database in a special use case scenario.

Can you please elaborate on this because I saw the same on alfresco wiki too, but couldn't understand.


Thanks,

afaust
Legendary Innovator
Legendary Innovator
Hello,

since SOLR is a separate server you might be suffering from issues in communication / process switching. These would not be related to Alfresco in general, but simply be a matter of your infrastructure setup, scalability etc. Lucene always runs in the same Java VM as Alfresco, so the there are several cost factors that are naturally avoided. In overall and due to some other architectural aspects, SOLR results should on average be available faster than Lucene results, especially with larger data sets (i.e. 1,000, 10,000, 100,000 … users) in a proper setup (CPU / RAM constraints not too tight, no significant latency on communication layer… ).

I would have to check on the people search to go into more details, as it's been a while since I've last looked at it. Currently, I am mobile without source code at hand…

Regards
Axel

sujaypillai
Confirmed Champ
Confirmed Champ
Hello Axel,

Right now the SOLR is running on the same tomcat as Alfresco.

And now I am getting below error -

Jul 31, 2012 8:49:32 PM org.quartz.core.ErrorLogger schedulerError
SEVERE: Job (Solr.CoreTracker-archive threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: org.alfresco.error.AlfrescoRuntimeException: 06310000 GetModelsDiff return status is 404]
   at org.quartz.core.JobRunShell.run(JobRunShell.java:227)
   at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:563)
Caused by: org.alfresco.error.AlfrescoRuntimeException: 06310000 GetModelsDiff return status is 404
   at org.alfresco.solr.client.SOLRAPIClient.getModelsDiff(SOLRAPIClient.java:1031)
   at org.alfresco.solr.tracker.CoreTracker.trackModels(CoreTracker.java:1808)
   at org.alfresco.solr.tracker.CoreTracker.trackRepository(CoreTracker.java:1170)
   at org.alfresco.solr.tracker.CoreTracker.updateIndex(CoreTracker.java:529)
   at org.alfresco.solr.tracker.CoreTrackerJob.execute(CoreTrackerJob.java:45)
   at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
   … 1 more


Thanks,

jpfi
Champ in-the-making
Champ in-the-making
Hi,
404 = not Found –> either your /alfresco webapp is running & solr is unable to find it (e.g. wrong url) or your /alfresco webapp isn't running.
It's maybe helpful if you post your whole log file.

By the way:
people-finder uses an DB-query (canned query) id your search term contains only one word:
"pan" -> DB-Query that queries all cmSmiley Tongueerson objects + java based filtering (IMHO bad designed)
"peter pan": -> runs a search subsystem query

cheers,
jan

sujaypillai
Confirmed Champ
Confirmed Champ
Hello Jan,

Yes my Alfresco app was down. I rebuild the SOLR indexes and its working fine now.

So you mean to say that SOLR doesn't have any role in people-finder search?
Any hints what can be the issue with the people-finder having long response time. The same thing was working fine when we were using LUCENE.


Thanks,

jpfi
Champ in-the-making
Champ in-the-making
hi,
it uses SOLR if you have more than one search term (e.g. "peter pan") or a leading wildcard ("*pan")…
How long is long?
How many users (cmSmiley Tongueerson) do you have?
What's your DB?

cheers, jan

sujaypillai
Confirmed Champ
Confirmed Champ
We have around 91K+ users synced from AD and it takes around 20-25secs for the search result to be returned.

We have PostgreSQL as DB.


Thanks,

jpfi
Champ in-the-making
Champ in-the-making
hi,
well, 90k is a lot. You can assume that querying 90k rows via sql & filter them is not the best approach in this case.
You should;
1. open a ticket here: issues.alfresco.com/jira/ & post it here, so other people can directly vote for it
2. implement a work around: org\alfresco\repository\person\people.get.js
// Get the args
var filter = args["filter"];
var maxResults = args["maxResults"];

// BEGIN FME PATCH: Fix for slow person queries with >10000 users
if (filter.indexOf(" ") == -1) {
  // Add a dummy * prefix filter to force the personService to use a SOLR query and not a CannedQuery
  filter = "*"+filter;
}
// END FME PATCH: Fix for slow person queries with >10000 users

// Get the collection of people
var peopleCollection = people.getPeople(filter, maxResults != null ? parseInt(maxResults) : 0);

// Pass the queried sites to the template
model.peoplelist = peopleCollection;

there are a few more webscripts where persons are searched: e.g. org\alfresco\repository\person\person.sites.get.js

cheers,
jan