You might compare the fedoragsearch.log with the three solr logs at a certain
point in time, look for the corresponding operations in each, if that does not
give you a clue, select some parts of the logs, that you think may contain
clues for me or others, and show them here. Also compare logs when triggered by
Fedora, versus when called "manually".
Gert
On 13/09/2012, at 13.13, Enrico Anello wrote:
> Hi gert,
> the configurations are the same, just copied over the wars and reconfigured
> changing hostnames and ports to suit the new server.
>
> the file: fedoragsearch/WEB-INF/classes/config/fedoragsearch.properties has
> the definition of the three solr cores names in
> fedoragsearch.indexNames = core1 core2 core3
>
> under the folder fedoragsearch/WEB-INF/classes/config/index/ I have 3 folders
> defining the 3 cores with inside each their index.properties
>
> Best,
> Enrico
>
>
>
>
> On 09/13/2012 12:36 PM, Gert Schmeltz Pedersen wrote:
>> Is your gsearch configuration exactly the same under the new tomcat instance
>> as under the previous one?
>>
>> Is your solr configuration exactly the same?
>>
>> What gsearch knows about your solr cores is in the index.properties of your
>> configuration, do you have more than one index.properties? if so, they are
>> listed in fedoragsearch.properties.
>>
>> Gert
>>
>>
>> On 13/09/2012, at 12.12, Enrico Anello wrote:
>>
>>> Dear all,
>>> I am facing since yesterday a weird problem where I'm missing some
>>> needles....
>>> We are using a gsearch instance triggered everytime fedora gets an object
>>> ingested. The gsearch has to update three different Solr cores based on
>>> different rules.
>>> Yesterday we moved all the environment on a new server where the only
>>> difference from the old one is that we installed gsearch on a different
>>> tomcat instance.
>>>
>>> Now, when we test some ingest from ours back-ends just one core gets
>>> updated while the others aren't, the document goes always on the same core!
>>> If I take the PID of the new object ingested in fedora and I try to do a
>>> manual update of the cores using the gsearch backend located on
>>> [hostname]/fedoragsearch/rest?operation=updateIndex then all the three
>>> cores get successfully updated as it should be.
>>>
>>> I increased the logging of all the components at the maximum level and
>>> there are no errors at all when it performs the automatic updates from
>>> fedora triggers.
>>> I'm stuck since yesterday reading thousands of lines of logs trying to
>>> find the needle but I don't find anything that addresses me to the real
>>> problem.
>>> If the manual update works I guess that all the configurations are properly
>>> done; It sounds like gsearch does not know about other cores when it gets
>>> triggered by fedora but I don't know why...
>>>
>>> Any help would be really appreciated.
>>>
>>> Best Regards,
>>> Enrico Anello
>>> Food and Agriculture Organization of the United Nations
>>> Via delle terme di Caracalla, 1 - 00100 Rome, Italy
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
>>> Fedora-commons-users mailing list
>>> Fedora-commons-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Fedora-commons-users mailing list
> Fedora-commons-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
