Hi Nilani,
Are there any hints in the logs indicating why the second gsearch instance
is not starting up?
I'm not sure I follow exactly how you have things set up. Are you running a
single tomcat with Fedora and two instances of gsearch? It may be helpful to
split out the apps into their own containers in order to track down where
the problem lies. You may also want to consider running your own message
broker rather than just using the one included with Fedora. The Fedora
messaging client that GSearch uses does include a mechanism to wait for the
broker to be available before attempting to connect, but it will eventually
time out. If that happens, gsearch won't get any updates. Running the broker
(an instance of ActiveMQ) as a stand-alone process will ensure that it's
available when each of the gsearch apps attempt to connect to it.
Bill
On Fri, Sep 24, 2010 at 10:32 AM, Nilani Ganeshwaran <
[email protected]> wrote:
> Hi Bill
>
>
>
> Thank you for your email. I am making sure both of the gsearch instances’
> update listeners are running with separate
>
> Client ids. First instance of gsearch getting updated without any problem.
> But when I restart the tomcat second instance of gsearch not getting
> updated; but if I change the client id and restart the tomcat it is getting
> updated again.
>
>
>
> Regards
>
> Nilani
>
>
>
> Nilani Ganeshwaran
>
> eScholar Software Developer
>
> The University of Manchester
>
> Tel: 0161 2758728
>
>
>
> *From:* Bill Branan [mailto:[email protected]]
> *Sent:* 24 September 2010 14:00
> *To:* Gert Schmeltz Pedersen
> *Cc:* [email protected];
> [email protected]
> *Subject:* Re: [fcrepo-dev] gsearch with solr 1.4
>
>
>
> Hi Nilani,
>
>
>
> I just wanted to confirm your thoughts about the update listener: you do
> want to ensure that each gsearch client uses its own value for client.id.
> The JMS listener in the update listener will create a durable subscription
> based on that id, meaning that even if the listener drops out and comes
> back, all messages will still be delivered. If you use the same id for two
> listeners, only one of them will get those "durable" messages. This is
> likely why you were seeing inconsistent message delivery. It is expected
> that each gsearch instance communicating with a single Fedora (actually with
> a single JMS broker) will have its own client.id value.
>
>
>
> Bill
>
> On Fri, Sep 24, 2010 at 7:35 AM, Gert Schmeltz Pedersen <[email protected]>
> wrote:
>
> Hi Nilani
>
>
>
> Thank you for this feedback. The solr autocommit is the key to it, I had
> forgot about it, but it is actually set on in the DemoOnSolr config in
> gsearch.
>
>
>
> I do not know much about the update listener, but changing the client.idto
> ensure uniqueness sounds right.
>
>
>
> Regards
>
> Gert
>
>
>
>
>
> On 24/09/2010, at 11.35, Nilani Ganeshwaran wrote:
>
>
>
> Hi Gert
>
>
>
> Thank you very for you advice on setting up gsearch with solr 1.4. I am
> successfully running gsearch 2.2 with solr 1.4. As you have mentioned I have
> copied lucene-core-2.9.2.jar to lib.
>
>
>
> I am summarising the problems I had and solutions here; this might be
> helpful to others who are planning to move to solr 1.4 with gsearch. Also I
> need your advice on couple of questions at the end.
>
>
>
> I had a problem in added documents to index not showing up in the solr
> search results. I thought this is because gsearch might not be doing an
> explicit commit after each add to index, I enabled auto commit in
> solrConfig.xml. After this each added document to the index in shown in the
> solr search results immediately.
>
>
>
> Basically one fedora repository is indexed using two instances of gsearch
> as below.
>
> - First instance of gsearch using licence 2.4
>
> - Second instance of gsearch using solr 1.4
>
>
>
> I am using update listener on gsearch side to receive the messages. First
> instance of gserach receiving messages without any problem, second instance
> some times not receiving messages but if I change client id in
> updater.properties it starts working.
>
>
>
> Questions
>
> -------------
>
> 1. How I can solve the problem with update listener?
>
>
>
> 2. When I read about solr commit operation it is mentioned in several
> places not to commit after each add; do commit as a batch process. But for
> our repository with 200,000 objects we need immediate refresh of search
> results. I have added 1000 objects to the repository in 10 mins without any
> problem (with commit after each add). Do you have any thoughts?
>
>
>
> Regards
>
> Nilani
>
>
>
>
>
>
>
> Nilani Ganeshwaran
>
> eScholar Software Developer
>
> Red 1.1, The John Rylands University Library
>
> The University of Manchester
>
> Oxford Road, Manchester, M13 9PP
>
> Tel: 0161 2758728
>
> Web: http://www.escholar.manchester.ac.uk
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Fedora-commons-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
>
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
