Christophe's contributions Fwd: [infinispan-commits] Infinispan SVN: r420 - in trunk/core/src: main/resources/xslt and 2 other directories.
by Manik Surtani
Congrats on your first contribution, Christophe! The first of many, I
hope.
Begin forwarded message:
> From: infinispan-commits(a)lists.jboss.org
> Date: 9 June 2009 22:29:03 BST
> To: infinispan-commits(a)lists.jboss.org
> Subject: [infinispan-commits] Infinispan SVN: r420 - in trunk/core/
> src: main/resources/xslt and 2 other directories.
> Reply-To: infinispan-commits(a)lists.jboss.org
>
> Author: chivert
> Date: 2009-06-09 17:29:03 -0400 (Tue, 09 Jun 2009)
> New Revision: 420
>
> Added:
> trunk/core/src/main/resources/xslt/ehcache16x2infinispan4x.xslt
> trunk/core/src/test/resources/configs/ehcache16/
> trunk/core/src/test/resources/configs/ehcache16/ehcache-
> configuration.xml
> trunk/core/src/test/resources/configs/ehcache16/ehcache.xsd
> Modified:
> trunk/core/src/main/java/org/infinispan/config/parsing/
> ConfigFilesConvertor.java
> Log:
> [ISPN-56] (Create migration script for EHCache) Adding style sheet
> for Ehcache configuration.
> Changing ConfigFilesConvertor to use this stylesheet.
> Adding Ehcache configuration examples and xsd for unit test. The
> unit test is not included in this change list though.
>
>
> Modified: trunk/core/src/main/java/org/infinispan/config/parsing/
> ConfigFilesConvertor.java
> ===================================================================
> --- trunk/core/src/main/java/org/infinispan/config/parsing/
> ConfigFilesConvertor.java 2009-06-09 15:55:01 UTC (rev 419)
> +++ trunk/core/src/main/java/org/infinispan/config/parsing/
> ConfigFilesConvertor.java 2009-06-09 21:29:03 UTC (rev 420)
> @@ -53,9 +53,9 @@
> */
> public class ConfigFilesConvertor {
>
> -
> private static final String JBOSS_CACHE3X = "JBossCache3x";
> - public static final String[] SUPPORTED_FORMATS = {JBOSS_CACHE3X};
> + private static final String EHCACHE_CACHE16X = "Ehcache16x";
> + public static final String[] SUPPORTED_FORMATS = {JBOSS_CACHE3X,
> EHCACHE_CACHE16X};
>
> public void parse(InputStream is, OutputStream os, String
> xsltFile) throws Exception {
> InputStream xsltInStream = new
> FileLookup().lookupFile(xsltFile);
> @@ -136,6 +136,8 @@
>
> if (type.equals(JBOSS_CACHE3X)) {
> transformFromJbossCache3x(sourceName, destinationName);
> + } else if (type.equals(EHCACHE_CACHE16X)) {
> + transformFromEhcache16x(sourceName, destinationName);
> }
>
> System.out.println("---");
> @@ -143,6 +145,7 @@
> System.out.println("---");
> }
>
> +
> private static void mustExist(String sourceName, String what) {
> if (sourceName == null) {
> System.err.println("Missing '" + what + "', cannot proceed");
> @@ -182,6 +185,28 @@
> }
> }
>
> + private static void transformFromEhcache16x(String sourceName,
> String destinationName) throws Exception {
> + File oldConfig = new File(sourceName);
> + if (!oldConfig.exists()) {
> + System.err.println("File specified as input ('" +
> sourceName + ") does not exist.");
> + System.exit(1);
> + }
> + ConfigFilesConvertor convertor = new ConfigFilesConvertor();
> + FileInputStream is = new FileInputStream(oldConfig);
> + File destination = new File(destinationName);
> + if (!destination.exists()) {
> + destination.createNewFile();
> + }
> +
> + FileOutputStream fos = new FileOutputStream(destinationName);
> + try {
> + convertor.parse(is, fos, "xslt/
> ehcache16x2infinispan4x.xslt");
> + } finally {
> + fos.close();
> + is.close();
> + }
> + }
> +
> private Transformer getTransformer(InputStream xsltInStream)
> throws TransformerConfigurationException {
> TransformerFactory tFactory = TransformerFactory.newInstance();
> StreamSource stylesource = new StreamSource(xsltInStream);
>
> Added: trunk/core/src/main/resources/xslt/ehcache16x2infinispan4x.xslt
> ===================================================================
> --- trunk/core/src/main/resources/xslt/
> ehcache16x2infinispan4x.xslt (rev 0)
> +++ trunk/core/src/main/resources/xslt/ehcache16x2infinispan4x.xslt
> 2009-06-09 21:29:03 UTC (rev 420)
> @@ -0,0 +1,145 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +
> +<xsl:stylesheet xmlns="urn:infinispan:config:4.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform
> " version="1.0">
> + <xsl:output method="xml" indent="yes" version="1.0"
> encoding="UTF-8" omit-xml-declaration="no"/>
> + <xsl:template match="/ehcache">
> + <xsl:comment>
> + This XSL stylesheet is used to convert an Ehcache 1.6.x
> configuration into an Infinispan 4.0.x configuration.
> + Note that Infinispan supports JGroups only, caches are
> migrated to using JGroups.
> + Peer discovery will also be using JGroups. Eviction
> policies are translated to LRU, FIFO or NONE.
> + </xsl:comment>
> + <xsl:element name="infinispan">
> +
> + <xsl:element name="global">
> + <xsl:element name="asyncListenerExecutor">
> + <xsl:attribute
> name="factory">org.infinispan.executors.DefaultExecutorFactory</
> xsl:attribute>
> + <property name="threadNamePrefix"
> value="AsyncListenerThread"/>
> + </xsl:element>
> +
> + <xsl:element name="asyncSerializationExecutor">
> + <xsl:attribute
> name="factory">org.infinispan.executors.DefaultExecutorFactory</
> xsl:attribute>
> + <property name="threadNamePrefix"
> value="AsyncSerializationThread"/>
> + </xsl:element>
> +
> + <evictionScheduledExecutor
> factory="org.infinispan.executors.DefaultScheduledExecutorFactory">
> + <property name="threadNamePrefix"
> value="EvictionThread"/>
> + </evictionScheduledExecutor>
> +
> + <replicationQueueScheduledExecutor
> factory="org.infinispan.executors.DefaultScheduledExecutorFactory">
> + <property name="threadNamePrefix"
> value="ReplicationQueueThread"/>
> + </replicationQueueScheduledExecutor>
> +
> + <xsl:element name="globalJmxStatistics">
> + <xsl:attribute name="jmxDomain">infinispan</
> xsl:attribute>
> + <xsl:attribute name="enabled">
> + <xsl:text>true</xsl:text>
> + </xsl:attribute>
> + </xsl:element>
> +
> + <xsl:element name="shutdown">
> + <xsl:attribute name="hookBehavior">
> + <xsl:text>DEFAULT</xsl:text>
> + </xsl:attribute>
> + </xsl:element>
> + </xsl:element>
> +
> + <xsl:element name="default">
> + <xsl:if test="defaultCache[@memoryStoreEvictionPolicy]">
> + <xsl:if
> test="contains(defaultCache[@memoryStoreEvictionPolicy], 'LRU')">
> + <xsl:element name="eviction">
> + <xsl:attribute name="strategy">
> + <xsl:value-of select="defaultCache/
> @memoryStoreEvictionPolicy"/>
> + </xsl:attribute>
> + </xsl:element>
> + </xsl:if>
> + <xsl:if
> test="contains(defaultCache[@memoryStoreEvictionPolicy], 'FIFO')">
> + <xsl:element name="eviction">
> + <xsl:attribute name="strategy">
> + <xsl:value-of select="defaultCache/
> @memoryStoreEvictionPolicy"/>
> + </xsl:attribute>
> + </xsl:element>
> + </xsl:if>
> + <xsl:if
> test="contains(defaultCache[@memoryStoreEvictionPolicy], 'LFU')">
> + <xsl:message terminate="no">WARNING!!! Infinispan
> does not support LFU eviction. Using LRU instead.
> + </xsl:message>
> + <xsl:element name="eviction">
> + <xsl:attribute name="strategy">
> + <xsl:text>LRU</xsl:text>
> + </xsl:attribute>
> + </xsl:element>
> + </xsl:if>
> + </xsl:if>
> +
> + </xsl:element>
> + <xsl:for-each select="cache">
> + <xsl:element name="namedCache">
> + <xsl:attribute name="name">
> + <xsl:value-of select="@name"/>
> + </xsl:attribute>
> + <xsl:element name="eviction">
> + <xsl:attribute name="strategy">
> + <xsl:choose>
> + <xsl:when
> test="contains(@memoryStoreEvictionPolicy, 'LRU')">
> + <xsl:text>LRU</xsl:text>
> + </xsl:when>
> + <xsl:otherwise>
> + <xsl:choose>
> + <xsl:when
> test="contains(@memoryStoreEvictionPolicy, 'FIFO')">
> + <xsl:text>FIFO</xsl:text>
> + </xsl:when>
> + <xsl:otherwise>
> + <xsl:choose>
> + <xsl:when
> test="contains(@memoryStoreEvictionPolicy, 'LFU')">
> + <xsl:text>LRU</xsl:text>
> + </xsl:when>
> + <xsl:otherwise>
> + <xsl:text>NONE</xsl:text>
> + </xsl:otherwise>
> + </xsl:choose>
> + </xsl:otherwise>
> + </xsl:choose>
> + </xsl:otherwise>
> + </xsl:choose>
> + </xsl:attribute>
> + </xsl:element>
> + <!-- <expiration lifespan="60000" maxIdle="1000" />
> -->
> + <xsl:element name="expiration">
> +
> + </xsl:element>
> +
> + <xsl:if test="cacheEventListenerFactory">
> + <xsl:element name="clustering">
> + <xsl:if test="cacheEventListenerFactory/
> @properties">
> + <xsl:attribute name="mode">
> + <!-- Replication, Invalidation,
> Distribution-->
> + <xsl:text>distribution</xsl:text>
> + </xsl:attribute>
> + <!-- TODO remove spaces -->
> + <xsl:choose>
> + <xsl:when
> test="contains(cacheEventListenerFactory/@properties,
> 'replicateAsynchronously=false')">
> + <xsl:element name="sync">
> + <!-- replQueueInterval="100"
> replQueueMaxElements="200" ?? -->
> + <xsl:attribute name="useReplQueue">
> + <xsl:text>true</xsl:text>
> + </xsl:attribute>
> + </xsl:element>
> + </xsl:when>
> + <xsl:otherwise>
> + <xsl:element name="async">
> + <!-- replQueueInterval="100"
> replQueueMaxElements="200" ?? -->
> + <xsl:attribute name="useReplQueue">
> + <xsl:text>true</xsl:text>
> + </xsl:attribute>
> + </xsl:element>
> + </xsl:otherwise>
> + </xsl:choose>
> + </xsl:if>
> + </xsl:element>
> + </xsl:if>
> + </xsl:element>
> + </xsl:for-each>
> + </xsl:element>
> +
> +
> + </xsl:template>
> +</xsl:stylesheet>
>
> Added: trunk/core/src/test/resources/configs/ehcache16/ehcache-
> configuration.xml
> ===================================================================
> --- trunk/core/src/test/resources/configs/ehcache16/ehcache-
> configuration.xml (rev 0)
> +++ trunk/core/src/test/resources/configs/ehcache16/ehcache-
> configuration.xml 2009-06-09 21:29:03 UTC (rev 420)
> @@ -0,0 +1,584 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +
> +<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> + xsi:noNamespaceSchemaLocation="ehcache.xsd" >
> +
> + <!--
> + CacheManager Configuration
> + ==========================
> + An ehcache.xml corresponds to a single CacheManager.
> +
> + See instructions below or the ehcache schema (ehcache.xsd) on
> how to configure.
> +
> + System property tokens can be specified in this file which are
> replaced when the configuration
> + is loaded. For example multicastGroupPort=${multicastGroupPort}
> can be replaced with the
> + System property either from an environment variable or a system
> property specified with a
> + command line switch such as -DmulticastGroupPort=4446.
> +
> + DiskStore configuration
> + =======================
> +
> + The diskStore element is optional. To turn off disk store path
> creation, comment out the diskStore
> + element below.
> +
> + Configure it if you have overflowToDisk or diskPersistent
> enabled for any cache.
> +
> + If it is not configured, and a cache is created which requires
> a disk store, a warning will be
> + issued and java.io.tmpdir will automatically be used.
> +
> + diskStore has only one attribute - "path". It is the path to
> the directory where
> + .data and .index files will be created.
> +
> + If the path is one of the following Java System Property it is
> replaced by its value in the
> + running VM. For backward compatibility these are not specified
> without being enclosed in the ${token}
> + replacement syntax.
> +
> + The following properties are translated:
> + * user.home - User's home directory
> + * user.dir - User's current working directory
> + * java.io.tmpdir - Default temp file path
> + * ehcache.disk.store.dir - A system property you would normally
> specify on the command line
> + e.g. java -Dehcache.disk.store.dir=/u01/myapp/diskdir ...
> +
> + Subdirectories can be specified below the property e.g.
> java.io.tmpdir/one
> + -->
> + <diskStore path="java.io.tmpdir"/>
> +
> + <!--
> + CacheManagerEventListener
> + =========================
> + Specifies a CacheManagerEventListenerFactory which is notified
> when Caches are added
> + or removed from the CacheManager.
> +
> + The attributes of CacheManagerEventListenerFactory are:
> + * class - a fully qualified factory class name
> + * properties - comma separated properties having meaning only
> to the factory.
> +
> + Sets the fully qualified class name to be registered as the
> CacheManager event listener.
> +
> + The events include:
> + * adding a Cache
> + * removing a Cache
> +
> + Callbacks to listener methods are synchronous and
> unsynchronized. It is the responsibility
> + of the implementer to safely handle the potential performance
> and thread safety issues
> + depending on what their listener is doing.
> +
> + If no class is specified, no listener is created. There is no
> default.
> + -->
> + <cacheManagerEventListenerFactory class="" properties=""/>
> +
> +
> + <!--
> + CacheManagerPeerProvider
> + ========================
> + (For distributed operation)
> +
> + Specifies a CacheManagerPeerProviderFactory which will be used
> to create a
> + CacheManagerPeerProvider, which discovers other CacheManagers
> in the cluster.
> +
> + One or more providers can be configured. The first one in the
> ehcache.xml is the default, which is used
> + for replication and bootstrapping.
> +
> + The attributes of cacheManagerPeerProviderFactory are:
> + * class - a fully qualified factory class name
> + * properties - comma separated properties having meaning only
> to the factory.
> +
> + Providers are available for RMI, JGroups and JMS as shown
> following.
> +
> + RMICacheManagerPeerProvider
> + +++++++++++++++++++++++++++
> +
> + Ehcache comes with a built-in RMI-based distribution system
> with two means of discovery of
> + CacheManager peers participating in the cluster:
> + * automatic, using a multicast group. This one automatically
> discovers peers and detects
> + changes such as peers entering and leaving the group
> + * manual, using manual rmiURL configuration. A hardcoded list
> of peers is provided at
> + configuration time.
> +
> + Configuring Automatic Discovery:
> + Automatic discovery is configured as per the following example:
> + <cacheManagerPeerProviderFactory
> +
> class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
> + properties="peerDiscovery=automatic,
> multicastGroupAddress=230.0.0.1,
> + multicastGroupPort=4446,
> timeToLive=32"/>
> +
> + Valid properties are:
> + * peerDiscovery (mandatory) - specify "automatic"
> + * multicastGroupAddress (mandatory) - specify a valid multicast
> group address
> + * multicastGroupPort (mandatory) - specify a dedicated port for
> the multicast heartbeat
> + traffic
> + * timeToLive - specify a value between 0 and 255 which
> determines how far the packets will
> + propagate.
> +
> + By convention, the restrictions are:
> + 0 - the same host
> + 1 - the same subnet
> + 32 - the same site
> + 64 - the same region
> + 128 - the same continent
> + 255 - unrestricted
> +
> + Configuring Manual Discovery:
> + Manual discovery is configured as per the following example:
> + <cacheManagerPeerProviderFactory class=
> +
> "net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
> + properties="peerDiscovery=manual,
> + rmiUrls=//server1:40000/sampleCache1|//
> server2:40000/sampleCache1
> + | //server1:40000/sampleCache2|//
> server2:40000/sampleCache2"
> + propertySeparator="," />
> +
> + Valid properties are:
> + * peerDiscovery (mandatory) - specify "manual"
> + * rmiUrls (mandatory) - specify a pipe separated list of
> rmiUrls, in the form
> + //hostname:port
> +
> + The hostname is the hostname of the remote CacheManager peer.
> The port is the listening
> + port of the RMICacheManagerPeerListener of the remote
> CacheManager peer.
> +
> + JGroupsCacheManagerPeerProvider
> + +++++++++++++++++++++++++++++++
> + <cacheManagerPeerProviderFactory
> class
> =
> "net
> .sf
> .ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
> +
> properties
> ="connect=UDP(mcast_addr=231.12.21.132;mcast_port=45566;ip_ttl=32;
> +
> mcast_send_buf_size=150000;mcast_recv_buf_size=80000):
> +
> PING(timeout=2000;num_initial_members=6):
> +
> MERGE2(min_interval=5000;max_interval=10000):
> +
> FD_SOCK:VERIFY_SUSPECT(timeout=1500):
> +
> pbcast.NAKACK(gc_lag=10;retransmit_timeout=3000):
> + UNICAST(timeout=5000):
> +
> pbcast.STABLE(desired_avg_gossip=20000):
> + FRAG:
> +
> pbcast
> .GMS
> (join_timeout
> =5000;join_retry_timeout=2000;shun=false;print_local_addr=false)"
> + propertySeparator="::"
> + />
> + The only property necessary is the connect String used by
> jgroups to configure itself. Refer to the Jgroups documentation for
> explanation
> + of all the protocols. The example above uses UDP multicast. If
> the connect property is not specified the default JGroups connection
> will be
> + used.
> +
> +
> + JMSCacheManagerPeerProviderFactory
> + ++++++++++++++++++++++++++++++++++
> + <cacheManagerPeerProviderFactory
> +
> class
> ="net.sf.ehcache.distribution.jms.JMSCacheManagerPeerProviderFactory"
> + properties="..."
> + propertySeparator=","
> + />
> +
> + The JMS PeerProviderFactory uses JNDI to maintain message queue
> independence. Refer to the manual for full configuration
> + examples using ActiveMQ and Open Message Queue.
> +
> + Valid properties are:
> + * initialContextFactoryName (mandatory) - the name of the
> factory used to create the message queue initial context.
> + * providerURL (mandatory) - the JNDI configuration information
> for the service provider to use.
> + * topicConnectionFactoryBindingName (mandatory) - the JNDI
> binding name for the TopicConnectionFactory
> + * topicBindingName (mandatory) - the JNDI binding name for the
> topic name
> + * getQueueBindingName (mandatory only if using jmsCacheLoader)
> - the JNDI binding name for the queue name
> + * securityPrincipalName - the JNDI java.naming.security.principal
> + * securityCredentials - the JNDI java.naming.security.credentials
> + * urlPkgPrefixes - the JNDI java.naming.factory.url.pkgs
> + * userName - the user name to use when creating the
> TopicConnection to the Message Queue
> + * password - the password to use when creating the
> TopicConnection to the Message Queue
> + * acknowledgementMode - the JMS Acknowledgement mode for both
> publisher and subscriber. The available choices are
> + AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE
> and SESSION_TRANSACTED. The default is AUTO_ACKNOWLEDGE.
> + -->
> +
> + <cacheManagerPeerProviderFactory
> +
> class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
> + properties="peerDiscovery=automatic,
> + multicastGroupAddress=230.0.0.1,
> + multicastGroupPort=4446, timeToLive=1"
> + propertySeparator=","
> + />
> +
> +
> + <!--
> + CacheManagerPeerListener
> + ========================
> + (Enable for distributed operation)
> +
> + Specifies a CacheManagerPeerListenerFactory which will be used
> to create a
> + CacheManagerPeerListener, which
> + listens for messages from cache replicators participating in
> the cluster.
> +
> + The attributes of cacheManagerPeerListenerFactory are:
> + class - a fully qualified factory class name
> + properties - comma separated properties having meaning only to
> the factory.
> +
> + Ehcache comes with a built-in RMI-based distribution system.
> The listener component is
> + RMICacheManagerPeerListener which is configured using
> + RMICacheManagerPeerListenerFactory. It is configured as per the
> following example:
> +
> + <cacheManagerPeerListenerFactory
> +
> class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
> + properties="hostName=fully_qualified_hostname_or_ip,
> + port=40001,
> + remoteObjectPort=40002,
> + socketTimeoutMillis=120000"
> + propertySeparator="," />
> +
> + All properties are optional. They are:
> + * hostName - the hostName of the host the listener is running
> on. Specify
> + where the host is multihomed and you want to control the
> interface over which cluster
> + messages are received. Defaults to the host name of the
> default interface if not
> + specified.
> + * port - the port the RMI Registry listener listens on. This
> defaults to a free port if not specified.
> + * remoteObjectPort - the port number on which the remote
> objects bound in the registry receive calls.
> + This defaults to a free port if not
> specified.
> + * socketTimeoutMillis - the number of ms client sockets will
> stay open when sending
> + messages to the listener. This should be long enough for the
> slowest message.
> + If not specified it defaults to 120000ms.
> +
> + -->
> + <cacheManagerPeerListenerFactory
> +
> class
> ="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"/>
> +
> +
> + <!--
> + Cache configuration
> + ===================
> +
> + The following attributes are required.
> +
> + name:
> + Sets the name of the cache. This is used to identify the cache.
> It must be unique.
> +
> + maxElementsInMemory:
> + Sets the maximum number of objects that will be created in memory
> +
> + maxElementsOnDisk:
> + Sets the maximum number of objects that will be maintained in
> the DiskStore
> + The default value is zero, meaning unlimited.
> +
> + eternal:
> + Sets whether elements are eternal. If eternal, timeouts are
> ignored and the
> + element is never expired.
> +
> + overflowToDisk:
> + Sets whether elements can overflow to disk when the memory store
> + has reached the maxInMemory limit.
> +
> + The following attributes and elements are optional.
> +
> + timeToIdleSeconds:
> + Sets the time to idle for an element before it expires.
> + i.e. The maximum amount of time between accesses before an
> element expires
> + Is only used if the element is not eternal.
> + Optional attribute. A value of 0 means that an Element can idle
> for infinity.
> + The default value is 0.
> +
> + timeToLiveSeconds:
> + Sets the time to live for an element before it expires.
> + i.e. The maximum time between creation time and when an element
> expires.
> + Is only used if the element is not eternal.
> + Optional attribute. A value of 0 means that and Element can
> live for infinity.
> + The default value is 0.
> +
> + diskPersistent:
> + Whether the disk store persists between restarts of the Virtual
> Machine.
> + The default value is false.
> +
> + diskExpiryThreadIntervalSeconds:
> + The number of seconds between runs of the disk expiry thread.
> The default value
> + is 120 seconds.
> +
> + diskSpoolBufferSizeMB:
> + This is the size to allocate the DiskStore for a spool buffer.
> Writes are made
> + to this area and then asynchronously written to disk. The
> default size is 30MB.
> + Each spool buffer is used only by its cache. If you get
> OutOfMemory errors consider
> + lowering this value. To improve DiskStore performance consider
> increasing it. Trace level
> + logging in the DiskStore will show if put back ups are occurring.
> +
> + memoryStoreEvictionPolicy:
> + Policy would be enforced upon reaching the maxElementsInMemory
> limit. Default
> + policy is Least Recently Used (specified as LRU). Other
> policies available -
> + First In First Out (specified as FIFO) and Less Frequently Used
> + (specified as LFU)
> +
> + Cache elements can also contain sub elements which take the
> same format of a factory class
> + and properties. Defined sub-elements are:
> +
> + * cacheEventListenerFactory - Enables registration of listeners
> for cache events, such as
> + put, remove, update, and expire.
> +
> + * bootstrapCacheLoaderFactory - Specifies a
> BootstrapCacheLoader, which is called by a
> + cache on initialisation to prepopulate itself.
> +
> + * cacheExtensionFactory - Specifies a CacheExtension, a generic
> mechansim to tie a class
> + which holds a reference to a cache to the cache lifecycle.
> +
> + * cacheExceptionHandlerFactory - Specifies a
> CacheExceptionHandler, which is called when
> + cache exceptions occur.
> +
> + * cacheLoaderFactory - Specifies a CacheLoader, which can be
> used both asynchronously and
> + synchronously to load objects into a cache. More than one
> cacheLoaderFactory element
> + can be added, in which case the loaders form a chain which
> are executed in order. If a
> + loader returns null, the next in chain is called.
> +
> + RMI Cache Replication
> + +++++++++++++++++++++
> +
> + Each cache that will be distributed needs to set a cache event
> listener which replicates
> + messages to the other CacheManager peers. For the built-in RMI
> implementation this is done
> + by adding a cacheEventListenerFactory element of type
> RMICacheReplicatorFactory to each
> + distributed cache's configuration as per the following example:
> +
> + <cacheEventListenerFactory
> class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
> + properties="replicateAsynchronously=true,
> + replicatePuts=true,
> + replicatePutsViaCopy=false,
> + replicateUpdates=true,
> + replicateUpdatesViaCopy=true,
> + replicateRemovals=true
> + asynchronousReplicationIntervalMillis=<number of
> milliseconds"
> + propertySeparator="," />
> +
> + The RMICacheReplicatorFactory recognises the following
> properties:
> +
> + * replicatePuts=true|false - whether new elements placed in a
> cache are
> + replicated to others. Defaults to true.
> +
> + * replicatePutsViaCopy=true|false - whether the new elements are
> + copied to other caches (true), or whether a remove message is
> sent. Defaults to true.
> +
> + * replicateUpdates=true|false - whether new elements which
> override an
> + element already existing with the same key are replicated.
> Defaults to true.
> +
> + * replicateRemovals=true - whether element removals are
> replicated. Defaults to true.
> +
> + * replicateAsynchronously=true | false - whether replications are
> + asynchronous (true) or synchronous (false). Defaults to true.
> +
> + * replicateUpdatesViaCopy=true | false - whether the new
> elements are
> + copied to other caches (true), or whether a remove message is
> sent. Defaults to true.
> +
> + * asynchronousReplicationIntervalMillis=<number of
> milliseconds> - The asynchronous
> + replicator runs at a set interval of milliseconds. The
> default is 1000. The minimum
> + is 10. This property is only applicable if
> replicateAsynchronously=true
> +
> +
> + JGroups Replication
> + +++++++++++++++++++
> +
> + For the Jgroups replication this is done with:
> + <cacheEventListenerFactory
> class
> ="net.sf.ehcache.distribution.jgroups.JGroupsCacheReplicatorFactory"
> +
> properties="replicateAsynchronously=true, replicatePuts=true,
> + replicateUpdates=true, replicateUpdatesViaCopy=false,
> +
> replicateRemovals=true,asynchronousReplicationIntervalMillis=1000"/>
> + This listener supports the same properties as the
> RMICacheReplicationFactory.
> +
> +
> + JMS Replication
> + +++++++++++++++
> +
> + For JMS-based replication this is done with:
> + <cacheEventListenerFactory
> +
> class="net.sf.ehcache.distribution.jms.JMSCacheReplicatorFactory"
> + properties="replicateAsynchronously=true,
> + replicatePuts=true,
> + replicateUpdates=true,
> + replicateUpdatesViaCopy=true,
> + replicateRemovals=true,
> + asynchronousReplicationIntervalMillis=1000"
> + propertySeparator=","/>
> +
> + This listener supports the same properties as the
> RMICacheReplicationFactory.
> +
> + Cluster Bootstrapping
> + +++++++++++++++++++++
> + (RMI clusters only)
> +
> + The RMIBootstrapCacheLoader bootstraps caches in clusters where
> RMICacheReplicators are
> + used. It is configured as per the following example:
> +
> + <bootstrapCacheLoaderFactory
> +
> class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory"
> + properties="bootstrapAsynchronously=true,
> maximumChunkSizeBytes=5000000"
> + propertySeparator="," />
> +
> + The RMIBootstrapCacheLoaderFactory recognises the following
> optional properties:
> +
> + * bootstrapAsynchronously=true|false - whether the bootstrap
> happens in the background
> + after the cache has started. If false, bootstrapping must
> complete before the cache is
> + made available. The default value is true.
> +
> + * maximumChunkSizeBytes=<integer> - Caches can potentially be
> very large, larger than the
> + memory limits of the VM. This property allows the bootstraper
> to fetched elements in
> + chunks. The default chunk size is 5000000 (5MB).
> +
> +
> + Cache Exception Handling
> +
> + By default, most cache operations will propagate a runtime
> CacheException on failure. An
> + interceptor, using a dynamic proxy, may be configured so that a
> CacheExceptionHandler can
> + be configured to intercept Exceptions. Errors are not
> intercepted.
> +
> + It is configured as per the following example:
> +
> + <cacheExceptionHandlerFactory
> class="com.example.ExampleExceptionHandlerFactory"
> + properties="logLevel=FINE"/>
> +
> + Caches with ExceptionHandling configured are not of type Cache,
> but are of type Ehcache only,
> + and are not available using CacheManager.getCache(), but using
> CacheManager.getEhcache().
> +
> +
> + Cache Loader
> +
> + A default CacheLoader may be set which loads objects into the
> cache through asynchronous and
> + synchronous methods on Cache. This is different to the
> bootstrap cache loader, which is used
> + only in distributed caching.
> +
> + It is configured as per the following example:
> +
> + <cacheLoaderFactory
> class="com.example.ExampleCacheLoaderFactory"
> +
> properties="type=int,startCounter=10"/>
> +
> + Cache Extension
> +
> + CacheExtensions are a general purpose mechanism to allow
> generic extensions to a Cache.
> + CacheExtensions are tied into the Cache lifecycle.
> +
> + CacheExtensions are created using the CacheExtensionFactory
> which has a
> + <code>createCacheCacheExtension()</code> method which takes as
> a parameter a
> + Cache and properties. It can thus call back into any public
> method on Cache, including, of
> + course, the load methods.
> +
> + Extensions are added as per the following example:
> +
> + <cacheExtensionFactory
> class="com.example.FileWatchingCacheRefresherExtensionFactory"
> +
> properties="refreshIntervalMillis=18000, loaderTimeout=3000,
> + flushPeriod=whatever,
> someOtherProperty=someValue ..."/>
> +
> + -->
> +
> +
> + <!--
> + Mandatory Default Cache configuration. These settings will be
> applied to caches
> + created programmtically using CacheManager.add(String cacheName).
> +
> + The defaultCache has an implicit name "default" which is a
> reserved cache name.
> + -->
> + <defaultCache
> + maxElementsInMemory="10000"
> + eternal="false"
> + timeToIdleSeconds="120"
> + timeToLiveSeconds="120"
> + overflowToDisk="true"
> + diskSpoolBufferSizeMB="30"
> + maxElementsOnDisk="10000000"
> + diskPersistent="false"
> + diskExpiryThreadIntervalSeconds="120"
> + memoryStoreEvictionPolicy="LRU"
> + />
> +
> + <!--
> + Sample caches. Following are some example caches. Remove these
> before use.
> + -->
> +
> + <!--
> + Sample cache named sampleCache1
> + This cache contains a maximum in memory of 10000 elements, and
> will expire
> + an element if it is idle for more than 5 minutes and lives for
> more than
> + 10 minutes.
> +
> + If there are more than 10000 elements it will overflow to the
> + disk cache, which in this configuration will go to wherever
> java.io.tmp is
> + defined on your system. On a standard Linux system this will
> be /tmp"
> + -->
> + <cache name="sampleCache1"
> + maxElementsInMemory="10000"
> + maxElementsOnDisk="1000"
> + eternal="false"
> + overflowToDisk="true"
> + diskSpoolBufferSizeMB="20"
> + timeToIdleSeconds="300"
> + timeToLiveSeconds="600"
> + memoryStoreEvictionPolicy="LFU"
> + />
> +
> +
> + <!--
> + Sample cache named sampleCache2
> + This cache has a maximum of 1000 elements in memory. There is
> no overflow to disk, so 1000
> + is also the maximum cache size. Note that when a cache is
> eternal, timeToLive and
> + timeToIdle are not used and do not need to be specified.
> + -->
> + <cache name="sampleCache2"
> + maxElementsInMemory="1000"
> + eternal="true"
> + overflowToDisk="false"
> + memoryStoreEvictionPolicy="FIFO"
> + />
> +
> +
> + <!--
> + Sample cache named sampleCache3. This cache overflows to disk.
> The disk store is
> + persistent between cache and VM restarts. The disk expiry
> thread interval is set to 10
> + minutes, overriding the default of 2 minutes.
> + -->
> +
> + <cache name="sampleCache3"
> + maxElementsInMemory="500"
> + eternal="false"
> + overflowToDisk="true"
> + timeToIdleSeconds="300"
> + timeToLiveSeconds="600"
> + diskPersistent="true"
> + diskExpiryThreadIntervalSeconds="1"
> + memoryStoreEvictionPolicy="LFU"
> + />
> +
> +
> + <!--
> + Sample distributed cache named sampleDistributedCache1.
> + This cache replicates using defaults.
> + It also bootstraps from the cluster, using default properties.
> + -->
> + <cache name="sampleDistributedCache1"
> + maxElementsInMemory="10"
> + eternal="false"
> + timeToIdleSeconds="100"
> + timeToLiveSeconds="100"
> + overflowToDisk="false">
> + <cacheEventListenerFactory
> +
> class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"/>
> + <bootstrapCacheLoaderFactory
> +
> class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory"/>
> + </cache>
> +
> +
> + <!--
> + Sample distributed cache named sampleDistributedCache2.
> + This cache replicates using specific properties.
> + It only replicates updates and does so synchronously via copy
> + -->
> +
> + <cache name="sampleDistributedCache2"
> + maxElementsInMemory="10"
> + eternal="false"
> + timeToIdleSeconds="100"
> + timeToLiveSeconds="100"
> + overflowToDisk="false">
> + <cacheEventListenerFactory
> +
> class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
> + properties="replicateAsynchronously=false,
> replicatePuts=false,
> + replicatePutsViaCopy=false,
> replicateUpdates=true,
> + replicateUpdatesViaCopy=true,
> replicateRemovals=false"/>
> + </cache>
> +
> + <!--
> + Sample distributed cache named sampleDistributedCache3.
> + This cache replicates using defaults except that the
> asynchronous replication
> + interval is set to 200ms.
> + -->
> + <cache name="sampleDistributedCache3"
> + maxElementsInMemory="10"
> + eternal="false"
> + timeToIdleSeconds="100"
> + timeToLiveSeconds="100"
> + overflowToDisk="false">
> + <cacheEventListenerFactory
> +
> class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
> +
> properties="asynchronousReplicationIntervalMillis=200"/>
> + </cache>
> +
> +</ehcache>
>
> Added: trunk/core/src/test/resources/configs/ehcache16/ehcache.xsd
> ===================================================================
> --- trunk/core/src/test/resources/configs/ehcache16/
> ehcache.xsd (rev 0)
> +++ trunk/core/src/test/resources/configs/ehcache16/ehcache.xsd
> 2009-06-09 21:29:03 UTC (rev 420)
> @@ -0,0 +1,122 @@
> +<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified" version="1.6">
> + <xs:element name="ehcache" >
> + <xs:complexType>
> + <xs:sequence>
> + <xs:element minOccurs="0" maxOccurs="1"
> ref="diskStore"/>
> + <xs:element minOccurs="0" maxOccurs="1"
> + ref="cacheManagerEventListenerFactory"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> + ref="cacheManagerPeerProviderFactory"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> + ref="cacheManagerPeerListenerFactory"/>
> + <xs:element ref="defaultCache"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cache"/>
> + </xs:sequence>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="diskStore">
> + <xs:complexType>
> + <xs:attribute name="path" use="optional" />
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheManagerEventListenerFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheManagerPeerProviderFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheManagerPeerListenerFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <!-- add clone support for addition of cacheExceptionHandler.
> Important! -->
> + <xs:element name="defaultCache">
> + <xs:complexType>
> + <xs:sequence>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cacheEventListenerFactory"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cacheExtensionFactory"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cacheLoaderFactory"/>
> + <xs:element minOccurs="0" maxOccurs="1"
> ref="bootstrapCacheLoaderFactory"/>
> + <xs:element minOccurs="0" maxOccurs="1"
> ref="cacheExceptionHandlerFactory"/>
> + </xs:sequence>
> + <xs:attribute name="diskExpiryThreadIntervalSeconds"
> use="optional" type="xs:integer"/>
> + <xs:attribute name="diskSpoolBufferSizeMB"
> use="optional" type="xs:integer"/>
> + <xs:attribute name="diskPersistent" use="optional"
> type="xs:boolean"/>
> + <xs:attribute name="eternal" use="required"
> type="xs:boolean"/>
> + <xs:attribute name="maxElementsInMemory" use="required"
> type="xs:integer"/>
> + <xs:attribute name="memoryStoreEvictionPolicy"
> use="optional" type="xs:string"/>
> + <xs:attribute name="overflowToDisk" use="required"
> type="xs:boolean"/>
> + <xs:attribute name="timeToIdleSeconds" use="optional"
> type="xs:integer"/>
> + <xs:attribute name="timeToLiveSeconds" use="optional"
> type="xs:integer"/>
> + <xs:attribute name="maxElementsOnDisk" use="optional"
> type="xs:integer"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cache">
> + <xs:complexType>
> + <xs:sequence >
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cacheEventListenerFactory"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cacheExtensionFactory"/>
> + <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="cacheLoaderFactory"/>
> + <xs:element minOccurs="0" maxOccurs="1"
> ref="bootstrapCacheLoaderFactory"/>
> + <xs:element minOccurs="0" maxOccurs="1"
> ref="cacheExceptionHandlerFactory"/>
> + </xs:sequence>
> + <xs:attribute name="diskExpiryThreadIntervalSeconds"
> use="optional" type="xs:integer"/>
> + <xs:attribute name="diskSpoolBufferSizeMB"
> use="optional" type="xs:integer"/>
> + <xs:attribute name="diskPersistent" use="optional"
> type="xs:boolean"/>
> + <xs:attribute name="eternal" use="required"
> type="xs:boolean"/>
> + <xs:attribute name="maxElementsInMemory" use="required"
> type="xs:integer"/>
> + <xs:attribute name="memoryStoreEvictionPolicy"
> use="optional" type="xs:string"/>
> + <xs:attribute name="name" use="required"
> type="xs:string"/>
> + <xs:attribute name="overflowToDisk" use="required"
> type="xs:boolean"/>
> + <xs:attribute name="timeToIdleSeconds" use="optional"
> type="xs:integer"/>
> + <xs:attribute name="timeToLiveSeconds" use="optional"
> type="xs:integer"/>
> + <xs:attribute name="maxElementsOnDisk" use="optional"
> type="xs:integer"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheEventListenerFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="bootstrapCacheLoaderFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheExtensionFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheExceptionHandlerFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> + <xs:element name="cacheLoaderFactory">
> + <xs:complexType>
> + <xs:attribute name="class" use="required"/>
> + <xs:attribute name="properties" use="optional"/>
> + <xs:attribute name="propertySeparator" use="optional"/>
> + </xs:complexType>
> + </xs:element>
> +</xs:schema>
>
> _______________________________________________
> infinispan-commits mailing list
> infinispan-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-commits
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 10 months
JGroups 2.8 and Infinispan
by Manik Surtani
Guys I am seeing problems here again.
Vladimir, you mentioned the problems you saw earlier had to do with
nodes not being in the initial TCPPING discovery list.
In one of my dist rehash tests, I see this as well, although I don't
think it has to do with the initial discovery list.
The test (will be in SVN soon) is
o.i.distribution.RehashTest#testNoDataLoss()
The test starts 3 caches, populates state. So far so good.
Adds 3 more caches to the cluster. Now here, in the process of adding
these, some of the original nodes cannot "see" some new nodes even
though views have been installed, leading to dropped packets.
(the next part of the test kills the 3 original nodes, but the test
never gets this far).
This is the sort of message we see in the logs. Wonder if the "no
physical address" bit sheds any light. (Note that the JGroups address
has been replaced with CACHE1..CACHE6 in the logs for readability)
2009-06-11 11:28:59,854 WARN [org.jgroups.protocols.TCP]
(OOB-6,Infinispan-Cluster,CACHE3) no physical address for CACHE5,
dropping message
Also, just so you know, this works perfectly well with JGroups 2.7.0.GA.
Any thoughts/ideas?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 10 months
Question on Async Eviction and Correct Cache Usage
by Amin Abbaspour
Hi All,
Thanks for the great product. I have just started testing infinispan
and this is my first post in the list.
Sorry if my question are vivid. (maybe this is because of docs
lacking, which I hope to be fixed and enriched asap).
1. How can I config inifispan to persis my object asynchronously and
not as soon as they are change. I have developed a JDBC cache store
for myself (which works well) but evict or persist is still sync. here
is my config:
config.setEvictionStrategy(EvictionStrategy.FIFO);
config.setEvictionWakeUpInterval(60 * 1000);
config.setCacheMode(Configuration.CacheMode.INVALIDATION_ASYNC);
2. I have a counter/billing like object in which in every system event
some counters are increased and some values (e.g. credit) is
decreased. This happens hundred/thousand times in a second and should
be coherent across all nodes. What is the correct policy for this
case. Should I rebuild a new object every time and replace it in the
cache with the previous one? This solution will require me to create
an object many times. Is there any other (better) solution?
3. May I have a complete sample of using transactions (including
boilerplate code) how to get transaction object. I need this for
question #2 to work correctly.
4. AFAIK distributed locks are not implemented yet. When will they be
available?
Regards,
Amin Abbaspour
14 years, 10 months
Re: New stuff with HS
by Emmanuel Bernard
hey
On Jun 11, 2009, at 09:52, Navin Surtani wrote:
> Heya guys,
>
> Hope all's going well with you ...
>
> Was speaking to Manik about what needs to be done with Infinispan -
> not been doing any work on this for a while since I've had exams
> which are done now - and he was just telling me that you guys are
> working on abstracting HS from Core?
hum no, it's done, that's the work you have done basically.
Something can likely be done to abstract some of the query engine but
I'm not sure how much. This needs ot be experimented.
>
> Emmanuel: Manik told me that you guys spoke about this and that you
> both seem to want to use Lucene for Infinispan. I was hoping to have
> an idea about what you guys spoke about and also figure out how we
> should implement this.
The idea is to get the infinispan data indexed in Lucene and stored...
well in Lucene as well. HSearch would be the query engine of Infinispan.
One question was whether or not create a JPA-QL / JPA2 Criteria API
layer on top of Lucene queries at least for non join or simple join
queries. It's an orthogonal project though.
The idea was to index the local data (node-wise). We can call each
node to get a global result (we will need to adjust Hibernate Search
in this area as we only do local IndexReaders today but AFAIK that's
doable).
The hard problem to crack is how Hibernate Search will deduplicate the
results. Infinispan does partly duplicate data, hence the query will
return the same data several times.
>
> For the core changes in the query interface I picked out these 3
> main changes in order of importance: -
>
> 1 - What's new with Hibernate Search and it's backend. Also how we
> can work it into Infinispan. I imagine we take a similar plan of
> attack as we did with JBCS.
Not much that will impact you. We have a new backend that is JGroups
based. sow e have lucene, JMs and JGroups now.
>
> 2 - Use of interceptors within Infinispan as opposed to listeners
> with JBCS.
not sure what's the fundamental difference so OK :)
>
> 3 - Editions within the query/searchable module of Infinispan that
> take into account the new API.
>
yes
> So if you guys could tell me what's new, or tell me where to go look
> for stuff (blogs, wikis etc) that would be great.
One thing we are working on is massive indexing. Sanne can talk more
about that but I frankly don't think that will impact infinispan in
the near term.
The rest was under the hood optimizations and some cool new higher
level features.
>
> In terms of what's new, do you guys have any major changes to
> backend/API?
nope but I think that would be a good time to:
- think about sharing some of the search infrastructure
(FullTextQueryImpl has some reusable stuffs likely)
- rethink the query API after hearing feedback from users. (I was
not 100% happy with the JBCS API)
>
> Thanks plenty,
> Navin.
>
>
>
14 years, 10 months
keySet(), values() and entrySet() impl progress and some questions
by Galder Zamarreno
Hi all,
I'm making good progress with
https://jira.jboss.org/jira/browse/ISPN-94. I'm currently testing that
with DIST mode, only local contents are returned.
We had agreed that these operations should not be participating in
transactions and I assume that this is so that locks are not acquired.
From what I understand, to achieve this, CacheDelegate method
implementation would need to pass a icc.createNonTxInvocationContext(),
correct?
We also agreed that we needed to document the limitations in javadoc but
in which javadoc? Obviously, Map javadoc cannot be touched, so I suppose
we should redefine the ops in the Cache interface and document them
there, correct?
Finally, one note about the MVI. As per an IRC conversation with Manik,
the collections returned by these methods need to be modified so that
marshalled values are swapped by real values. The collections returned
by these methods are not currently ready to be mutable so instead I've
gone for the copying option changing the marshalled values to the real
objects.
I've taken this decision because:
- The implementation was simpler by just copying.
- Not sure there's much point in implementing mutable collections for
the return of these methods if we're only gonna need to mutate them for
the marshalled value edge case. The one advantage of mutable collections
would be the ability to swap the marshalled values directly without
copying, hence memory consumption would less.
- Remember that these collection returning methods should primarily used
for debugging and not for production, hence the extra memory consumption
for these type of methods doesn't sound like such a bad thing.
Thoughts?
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
14 years, 11 months
Infinispan configuration
by Vladimir Blagojevic
Hi,
I asked to work on "Document all configuration options available in XML
and the Configuration beans on the wiki" JIRA [1] thinking that it would
be a familiar task - something similar to what Bela and I did in JGroups.
However, now, after learning a bit about how infinispan is configured,
how configuration is maintained, I would suggest we do a bit more in a
scope of this task, if possible. Being a newbie, it is highly likely
that I am overlooking some details. I would keep all current
configuration beans, that is all subclasses of AbstractConfigurationBean
but introduce annotation(s) for those beans that would:
- have some form of configuration xpath element matching xml element in
conf file
- describe each configuration option in plain english
- ref to classes to process certain complex elements
and others as the need arise.
I would also:
- remove current hand maintained schema
- create schema by automated tools given metadata in annotations
- create all human readable documentation from these annotations ; my
original JIRA [1]
- read all configuration elements from xml using metadata in annotations
thus avoiding "by hand" reading we have now
Let me know what you think and especially you, Mircea (being most
familiar with conf), if you think this is feasible.
Regards,
Vladimir
[1] https://jira.jboss.org/jira/browse/ISPN-89
14 years, 11 months
ISPN-12 Optimize transactions spanning caches from the same cache manager
by Mircea Markus
Hi *,
Some thoughts I have about above JIRA.
Background:
CacheManager cm;
Cache c1 = cm.getCache("replicatedCacheConfig1");
Cache c2 = cm.getCache("replicatedCacheConfig2");
transactionManager.start();
c1.put(a,b);
c2.put(b,c);
transactionManager.commit(); // at this point there we replicate two
PrepareCommand and two CommitCommands , the JIRA is about aggregating
all prepares into one (same about commits) => less roundtrip
Considerations:
REPL: This functionality only makes sense if we have at least two active
replicated caches.
DIST: with DIST things can still be optimized in order to group
Prepare/Commit/RollbackCommands about to be replicated to the same nodes
If we have a tx spreading an ASYNC and an SYNC cache the optimization is
not supported for now.
Design notes:
GlobalTxRepository is (basically) a Map<Transaction, AtomicInt>: for
each Transaction it keeps an count(AtomicInt) of the caches that were
affected by a given Transaction.
Operations:
1. GlobalTxRepository.transactionRegistered(Transaction) will be called
whenever a TransactionXaAdapter is created. This will increment
Transaction's associated participant count. Call made from TransactionTable.
2. GlobalTxRepository.aboutToPrepare(Transaction) will be called when a
transaction is about to prepare, and will decrement the Transaction's
associated participant count. Call made from TxInterceptor
3. GlobalTxRepository.aboutToFinish(Transaction) will be called before a
transaction commits or rollbacks. Call made from TxInterceptor
ReplicationInterceptor and DistributionInterceptor:
In visitPrepare/visitCommit/visitRollback - will check if the
participant count associated with given tx is 0, if so will trigger
replication. This will make sure that only last participant will do the
actual replication.
Performance costs:
- there is a set of operations this functionality requires(map lookups,
atomic increments/decrements) which might be totally useless if user
won't use such transactions. There are some ways to reduce/avoid
performance costs:
a) only expose this functionality through Flags (extra Flag required.
Flag.OPTIMIZE_TX_REPLICATION ?)
b) allow the user to enable it statically through a configuration option
c) use a sort of ergonomics, for each 10th/n-th finishing transaction,
check weather it spread over more than one caches: if so enable the
functionality and keep it enabled for good
My personal vote is for b) for simplicity.
Any feedback much appreciated :)
Cheers,
Mircea
14 years, 11 months
Re: [infinispan-dev] Looking for volunteers: Interactive demo for Infinispan
by Alejandro Montenegro
I will start working on it asap. I believe I can have it done before your
time limit.
thanks
Alejandro
On Sun, Jun 7, 2009 at 10:31 AM, Manik Surtani <manik(a)jboss.org> wrote:
> Hi Alejandro.
> Sure, it would be great, however I would like to have something in place
> before I release Beta1 in about 2 weeks. Do you think you have the time for
> it so soon?
>
> Thanks
> Manik
>
> On 5 Jun 2009, at 15:37, Alejandro Montenegro wrote:
>
> hey Manik,
> this looks like a good opportunity for me to get more involved with
> infinispan, I will start working on this.. if its ok with you, please assign
> the issue to me..
>
> thanks
> Alejandro
>
> On Fri, Jun 5, 2009 at 7:10 AM, Manik Surtani <manik(a)jboss.org> wrote:
>
>> Guys
>>
>> At one stage we will need a step-by-step interactive tutorial for
>> Infinispan, to supplement the quick 5-minute guide [1] that I have up.
>>
>> I have created ISPN-95 [2] for this. Anyone volunteering for this? It is
>> a great learning opportunity for someone who wants to get into Infinispan
>> and a good excuse to learn the APIs and how things work. Details are on the
>> JIRA, but essentially what this is is a step-by-step guide through some
>> common use scenarios, using Groovy as an interactive console.
>>
>> Cheers
>> Manik
>>
>> [1] http://www.jboss.org/community/wiki/5minutetutorialonInfinispan
>> [2] https://jira.jboss.org/jira/browse/ISPN-95
>>
>> --
>> Manik Surtani
>> manik(a)jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> --
> Alejandro Montenegro del Pino.
> Viña del Mar - Chile
> phone: (+56) 9-68358690
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
--
Alejandro Montenegro del Pino.
Viña del Mar - Chile
phone: (+56) 9-68358690
14 years, 11 months
