-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: JMS configuration with immediate slave refresh
PostPosted: Mon Jun 10, 2013 5:31 pm 
Newbie

Joined: Mon Jun 10, 2013 4:31 pm
Posts: 2
Hi. I'm using Hibernate Search 4.1.1.Final with JMS master-slave cluster configuration.

I need a standard JMS master-slave configuration where slave also updates it's own (local) indexes immediately after (or before) sending notification to JMS queue.
Master refreshes slaves every 60 seconds and its not optimal for my system to decrease that value. Other slaves can wait the refresh time, but the slave originating work needs his indexes updated immediately.

So far I implemented my custom BackendQueueProcessor which wraps both JMSBackendQueueProcessor and LuceneBackendQueueProcessor and delegates each work to both of them.
However, when I use filesystem-slave directory provider, which seems proper for me, the slave indexes are correctly refreshed after those 60 seconds but there is no immediate change. When using filesystem direcotry provider, slave indexes are refreshed immediately, but not updated from master.
What configuration should I use or what should I implement to achieve my goal?

I'm using native locking strategy in slaves, if that's important in the case.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.