Highly appreciate the detailed replies and the clarifications on distributed
cache vs database.
We are trying to build a distributed cache. I agree to all the inputs you
shared for such a cache implementation. In summary it would mean
        1. Subscriber should clear the cache when it cannot connect to the 
broker
        2. Publisher should not rollback the database transaction on failures as
step #1 would be sufficient & the cache is loaded as and when queried

A couple of follow up questions
1. 

> Typically you would call it in a tight loop, so you're only as stale as
> the amount of time it takes you to publish the messages received the last
> time. 

        
How can one control the polling time of the consumer? My jms consumer code
from our spring application looks like this

@Component
public class Consumer {

          @JmsListener(destination = "java-topic", containerFactory =
"topicListenerFactory")
        public void receiveTopicMessage(@Payload Person person) throws 
JMSException
{
            //update the local cache entry
           }
}

How do I change the above code to call it in a tight loop? Also would that
mean one or more threads would be constantly busy leading to constant usage
of CPU cycles? 

2.
For my question on overloaded subscriber I didn't completely follow your
suggestion for not being worried about this scenario. You mentioned


>  If you're going with a distributed cache, then don't worry about
> this, because you'll handle it with queries to the truth store when you
> have cache misses (at the cost of slower performance). 

Assume there are two app servers with an object loaded in the local cache.
An update to this object occurs on app server 1 which publishes that object
on the jms queue. Here if app server 2 is overloaded (busy CPU), the jms
consumer thread might not get a chance to execute at that instance in time.
What happens in such cases, does activemq retry after some time? Can the
number of such retries be configured? It could so happen that the app server
2 could remain in an overloaded state for a longer duration (may be 30
mins).



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Reply via email to