Well,
thanks for time spent anyway,
Enrico
On 09/13/2012 04:09 PM, Gert Schmeltz Pedersen wrote:
I am afraid I do not see how the logs relate to fedoragsearch, I do
not know the classes, nor the contents of the log lines.
Gert
On 13/09/2012, at 14.57, Enrico Anello wrote:
Thanks a lot Gert,
here the logs. Solr has a common log for each core because are all
running on the same instance.
As you can see on the automatic trigger gsearch is called 3 times for
each of the workcentric object ingested in fedora while on the manual
run gsearch runs 3 times for the same object on the 3 different cores....
Best,
Enrico
On 09/13/2012 02:19 PM, Gert Schmeltz Pedersen wrote:
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
<mailto: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
<mailto:Fedora-commons-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
<logs.zip>------------------------------------------------------------------------------
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
<mailto: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
