Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
/**
* Copyright Terracotta, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package net.sf.ehcache.distribution;
import net.sf.ehcache.CacheException;
import net.sf.ehcache.Ehcache;
import net.sf.ehcache.Element;
import net.sf.ehcache.Status;
import java.lang.ref.SoftReference;
import java.rmi.UnmarshalException;
import java.util.ArrayList;
import java.util.List;
import java.util.Queue;
import java.util.concurrent.ConcurrentLinkedQueue;
import net.sf.ehcache.distribution.RmiEventMessage.RmiEventType;
import org.slf4j.LoggerFactory;
import org.slf4j.Logger;
/**
* Listens to {@link net.sf.ehcache.CacheManager} and {@link net.sf.ehcache.Cache} events and propagates those to
* {@link CachePeer} peers of the Cache asynchronously.
*
* Updates are guaranteed to be replicated in the order in which they are received.
*
* While much faster in operation than {@link RMISynchronousCacheReplicator}, it does suffer from a number
* of problems. Elements, which may be being spooled to DiskStore may stay around in memory because references
* are being held to them from {@link EventMessage}s which are queued up. The replication thread runs once
* per second, limiting the build up. However a lot of elements can be put into a cache in that time. We do not want
* to get an {@link OutOfMemoryError} using distribution in circumstances when it would not happen if we were
* just using the DiskStore.
*
* Accordingly, the Element values in {@link EventMessage}s are held by {@link java.lang.ref.SoftReference} in the queue,
* so that they can be discarded if required by the GC to avoid an {@link OutOfMemoryError}. A log message
* will be issued on each flush of the queue if there were any forced discards. One problem with GC collection
* of SoftReferences is that the VM (JDK1.5 anyway) will do that rather than grow the heap size to the maximum.
* The workaround is to either set minimum heap size to the maximum heap size to force heap allocation at start
* up, or put up with a few lost messages while the heap grows.
*
* @author Greg Luck
* @version $Id: RMIAsynchronousCacheReplicator.java 5631 2012-05-10 08:31:33Z teck $
*/
public class RMIAsynchronousCacheReplicator extends RMISynchronousCacheReplicator {
private static final Logger LOG = LoggerFactory.getLogger(RMIAsynchronousCacheReplicator.class.getName());
/**
* A thread which handles replication, so that replication can take place asynchronously and not hold up the cache
*/
private final Thread replicationThread = new ReplicationThread();
/**
* The amount of time the replication thread sleeps after it detects the replicationQueue is empty
* before checking again.
*/
private final int replicationInterval;
/**
* The maximum number of Element replication in single RMI message.
*/
private final int maximumBatchSize;
/**
* A queue of updates.
*/
private final Queue