[JBoss JIRA] Created: (JBCACHE-1409) Unnecessarily scary debug message during config parsing
by Brian Stansberry (JIRA)
Unnecessarily scary debug message during config parsing
-------------------------------------------------------
Key: JBCACHE-1409
URL: https://jira.jboss.org/jira/browse/JBCACHE-1409
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.GA
Reporter: Brian Stansberry
Assignee: Manik Surtani
Priority: Minor
XmlConfigurationParser.setValue logs a rather alarming message when it tries and fails to find a property setter that takes a String or Element:
2008-09-11 17:07:09,026 DEBUG [org.jboss.cache.factories.XmlConfigurationParser] (main) Unrecognised attribute SyncReplTimeout. Please check your configuration. Ignoring!!
It then goes on to look for a setter that takes a different type (in this case, long) and sets the property, or fails with an exception if there really is no appropriate setter.
It's only a DEBUG message, so this is minor, but the message itself is quite alarming. If there needs to be a message at all, perhaps "No property SyncReplTimeout of type String or Element; checking for other types."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1484) Jboss cache failed with external jgroups configuration
by sridhar reddy (JIRA)
Jboss cache failed with external jgroups configuration
------------------------------------------------------
Key: JBCACHE-1484
URL: https://jira.jboss.org/jira/browse/JBCACHE-1484
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Replication
Affects Versions: 3.0.2.GA
Environment: Windows XP, JDK 1.6, Jboss cache core 3.0.2 GA
Reporter: sridhar reddy
Assignee: Manik Surtani
Priority: Blocker
Fix For: 3.0.3.GA
I have the following jboss cache xml as below
[code]
<?xml version="1.0" encoding="UTF-8"?>
<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.0">
<locking isolationLevel="READ_COMMITTED"
lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
nodeLockingScheme="mvcc" writeSkewCheck="false"
concurrencyLevel="500" />
<transaction
transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
syncRollbackPhase="false" syncCommitPhase="false" />
<eviction wakeUpInterval="500">
<default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
eventQueueSize="200000">
<property name="maxNodes" value="5000" />
<property name="timeToLive" value="1000" />
</default>
<region name="/org/jboss/data1">
<property name="timeToLive" value="2000" />
</region>
<region name="/org/jboss/data2"
algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
eventQueueSize="100000">
<property name="maxNodes" value="3000" />
<property name="minTimeToLive" value="4000" />
</region>
</eviction>
<clustering mode="replication" >
<jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
</clustering>
<loaders passivation="false" shared="false">
<preload>
<node fqn="/" />
</preload>
<loader class="org.jboss.cache.loader.JDBCCacheLoader"
async="true" fetchPersistentState="true" ignoreModifications="true"
purgeOnStartup="true">
<properties>
cache.jdbc.table.name=jbosscache
cache.jdbc.table.create=true
cache.jdbc.table.drop=false
cache.jdbc.table.primarykey=jbosscache_pk
cache.jdbc.fqn.column=fqn
cache.jdbc.fqn.type=varchar(255)
cache.jdbc.node.column=node
cache.jdbc.node.type=bytea
cache.jdbc.parent.column=parent
cache.jdbc.driver=org.postgresql.Driver
cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
cache.jdbc.user=f7tms
cache.jdbc.password=f7tms
</properties>
</loader>
</loaders>
</jbosscache>
[/code]
and jgroups.xml file as below
[code]
<config>
<UDP mcast_addr="${jgroups.udp.mcast_addr:228.10.10.10}"
mcast_port="${jgroups.udp.mcast_port:45588}" tos="8"
ucast_recv_buf_size="20000000" ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000" mcast_send_buf_size="640000"
loopback="false" discard_incompatible_packets="true"
max_bundle_size="64000" max_bundle_timeout="30"
use_incoming_packet_handler="true" ip_ttl="${jgroups.udp.ip_ttl:2}"
enable_bundling="true" enable_diagnostics="true"
thread_naming_pattern="cl" use_concurrent_stack="true"
thread_pool.enabled="true" thread_pool.min_threads="2"
thread_pool.max_threads="8" thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true" thread_pool.queue_max_size="1000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Run" />
<PING timeout="2000" num_initial_members="3" />
<MERGE2 max_interval="30000" min_interval="10000" />
<FD_SOCK />
<FD timeout="10000" max_tries="5" shun="true" />
<VERIFY_SUSPECT timeout="1500" />
<BARRIER />
<pbcast.NAKACK use_stats_for_retransmission="false"
exponential_backoff="150" use_mcast_xmit="true" gc_lag="0"
retransmit_timeout="50,300,600,1200" discard_delivered_msgs="true" />
<UNICAST timeout="300,600,1200" />
<pbcast.STABLE stability_delay="1000"
desired_avg_gossip="50000" max_bytes="1000000" />
<VIEW_SYNC avg_send_interval="60000" />
<pbcast.GMS print_local_addr="true" join_timeout="3000"
shun="false" view_bundling="true" />
<FC max_credits="500000" min_threshold="0.20" />
<FRAG2 frag_size="60000" />
-
<!-- pbcast.STREAMING_STATE_TRANSFER /
-->
<pbcast.STATE_TRANSFER />
-
<!-- pbcast.FLUSH /
-->
</config>
[/code]
My code start the cache as
[code]
package org.gridgain.examples.jbosscache;
import java.io.File;
import org.jboss.cache.Cache;
import org.jboss.cache.CacheFactory;
import org.jboss.cache.DefaultCacheFactory;
import org.jboss.cache.Fqn;
import org.jboss.cache.Node;
import org.jboss.cache.config.Configuration;
import org.jboss.cache.config.parsing.XmlConfigurationParser;
import org.jgroups.JChannelFactory;
public final class GridJbossCacheManager {
/** Cache configuration path relative to GridGain installation. */
public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
/** JGroups configuration path relative to GridGain installation. */
public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
/** JBoss Cache instance. */
private Cache<Long, String> cache = null;
/** Cache node for caching example data. */
private Node<Long, String> cacheRoot = null;
/** Singleton instance. */
private static GridJbossCacheManager instance = new GridJbossCacheManager();
/**
* Gets singleton.
*
* @return Singleton.
*/
public static GridJbossCacheManager getInstance() {
return instance;
}
/**
* Ensure singleton.
*/
private GridJbossCacheManager() {
// No-op.
}
public void start() throws GridException {
File cacheCfg = new File(CACHE_CFG_PATH);
if (cacheCfg == null) {
throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
}
File jgroupsCfg = new File(JGROUPS_CFG_PATH);
if (jgroupsCfg == null) {
throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
}
// Make sure JBoss Cache and GridGain are on the same "wave length".
JChannelFactory factory = new JChannelFactory(); //null;
try {
//factory = new JChannelFactory(jgroupsCfg);
factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
}
catch (Exception e) {
throw new GridException("Failed to start Data Manager.", e);
}
try {
XmlConfigurationParser parser = new XmlConfigurationParser();
// Start JBoss Cache cache with shared JGroups configuration.
Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
// Instantiate and start JBoss Cache.
cache = dataFactory.createCache(svrCfg);
// Cache node for storing example data.
cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
}
catch (Exception e) {
throw new GridException("Failed to start Data Manager.", e);
}
System.out.println("JBoss Cache data manager started.");
}
}
[/code]
When i ran this program i am getting the following error
[code]
Exception in thread "main"
Exception:
----------
>>> Type: java.lang.Exception
>>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
>>> Stack trace:
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
Caused By:
----------
>>> Type: java.io.IOException
>>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
>>> Stack trace:
>>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
>>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
[/code]
Now i have added the
[code]
<protocol_stacks>
<stack name="udp"
description="Default: IP multicast based stack, with flow control and message bundling">
[/code]
to jgroups.xml. When i ran the program, its giving the following error.
[code]
log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
log4j:WARN Please initialize the log4j system properly.
Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
... 9 more
Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
... 14 more
Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
... 16 more
[/code]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBCACHE-1482) ActivationInterceptor leaks memory
by Krzysztof Sobolewski (JIRA)
ActivationInterceptor leaks memory
----------------------------------
Key: JBCACHE-1482
URL: https://jira.jboss.org/jira/browse/JBCACHE-1482
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
ActivationInterceptor in 2.2 branch has an ActivationModificationsBuilder, which in turn has a List<Modification> cacheLoaderModifications. This list is always added to and never removed from; I can see that there used to be a user of this list, but it's commented out (in CacheStoreInterceptor.handleCommitCommand()). The result is always increasing memory in passivation mode (under our normal load it fills up rather quickly).
>From what I can see, this list can be safely removed altogether, right?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBCACHE-1481) Re-adding a node deleted via parent inside transaction breaks the parent
by Krzysztof Sobolewski (JIRA)
Re-adding a node deleted via parent inside transaction breaks the parent
------------------------------------------------------------------------
Key: JBCACHE-1481
URL: https://jira.jboss.org/jira/browse/JBCACHE-1481
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.3.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: ReAddDeletedNodeTest.java
The scenario:
0. Start a transaction
1. Add a node under /a/a/a for example
2. Delete /a/a (the node's parent)
3. Add the node again
4. getNode(/a/a) now returns null [the DELETED flag is still set]
I'll attach a test case soon. And I'd like to note that that test actually exhibits more problems:
4a. getNode(/a/a/a) returns node as expected
5. Commit transaction
6a. getNode(/a/a/a) returns null (!!)
6b. getNode(/a/a) still returns null
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBCACHE-1479) Loads nodes from cache loader too aggresively
by Krzysztof Sobolewski (JIRA)
Loads nodes from cache loader too aggresively
---------------------------------------------
Key: JBCACHE-1479
URL: https://jira.jboss.org/jira/browse/JBCACHE-1479
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders, Transactions
Affects Versions: 3.0.2.GA, 3.1.0.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
I have a test that goes like this (all in the same thread):
0. populate cache with a single node, via a simple put().
1a. start transaction 1 (and suspend)
1b. start transaction 2 (and suspend)
2a. resume tx1
2b. get the node
2c. suspend tx1
3a. resume tx2
3b. get the node
3c. suspend tx2
4. resume and end both transactions
With 2.2 it works fine. With 3.x (3.0.2 and trunk) it timeouts on step 3b. The problem is that even though the node was added by me and was not evicted, the CacheLoaderInterceptor tries to load it for both transactions (steps 2b and 3b). This entails a write lock, hence a deadlock. From what I gather this is because the "data loaded" flag is never set on the node and it confuses the interceptor, which tries to load (and puts a write lock) on each and every access. My guess is that the flag should be set to true after put() -- if I do it "by hand", there is no deadlock (but then some other test fails, which means that I'm not qualified to fix this problem :) )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBCACHE-1478) java.lang.UnsupportedOperationException: Not supported in UnversionedNode
by Santhosh Kumar (JIRA)
java.lang.UnsupportedOperationException: Not supported in UnversionedNode
-------------------------------------------------------------------------
Key: JBCACHE-1478
URL: https://jira.jboss.org/jira/browse/JBCACHE-1478
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.2.GA
Environment: Windows XP
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
Java HotSpot(TM) Client VM (build 1.5.0_16-b02, mixed mode)
JBoss Cache version: JBossCache 'Naga' 3.0.2.GA
Reporter: Santhosh Kumar
Assignee: Manik Surtani
Getting java.lang.UnsupportedOperationException: Not supported in UnversionedNode when toString is invoked on a CacheServer which is not created.
Here is the stack trace.
Exception in thread "main" java.lang.UnsupportedOperationException: Not supported in UnversionedNode
at org.jboss.cache.AbstractNode.getChildrenDirect(AbstractNode.java:277)
at org.jboss.cache.mvcc.NodeReference.getChildrenDirect(NodeReference.java:267)
at org.jboss.cache.invocation.NodeInvocationDelegate.getChildrenDirect(NodeInvocationDelegate.java:163)
at org.jboss.cache.DataContainerImpl.numNodes(DataContainerImpl.java:454)
at org.jboss.cache.DataContainerImpl.getNumberOfNodes(DataContainerImpl.java:431)
at org.jboss.cache.DataContainerImpl.toString(DataContainerImpl.java:388)
at org.jboss.cache.DataContainerImpl.toString(DataContainerImpl.java:366)
at org.jboss.cache.invocation.CacheInvocationDelegate.toString(CacheInvocationDelegate.java:143)
at java.lang.String.valueOf(String.java:2615)
at java.lang.StringBuilder.append(StringBuilder.java:116)
at com.autodesk.it.common.cache.CacheTestCase.main(CacheTestCase.java:12)
Test Case:
import org.jboss.cache.Cache;
import org.jboss.cache.CacheFactory;
import org.jboss.cache.DefaultCacheFactory;
public class CacheTestCase {
public static void main(String[] args) {
CacheFactory<String, String> cacheFactory = new DefaultCacheFactory<String, String>();
Cache<String, String> cacheServer = cacheFactory.createCache(false);
System.out.println("Cache Server " + cacheServer);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBCACHE-1470) Option to disable cache event generation for a cache operation.
by Galder Zamarreno (JIRA)
Option to disable cache event generation for a cache operation.
---------------------------------------------------------------
Key: JBCACHE-1470
URL: https://jira.jboss.org/jira/browse/JBCACHE-1470
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 3.1.0.GA
For the prototype that I'm building for JBCACHE-816, I would like to implement a new Option that
disables generation of cache listener events for a particular cache operation.
Why is that I want to implement this? First, bear in mind that currently, I'm trying to get a prototype
done just by accessing the Cache interface (no SPI)
Take this scenario:
- Cluster 1 with nodes A, B and C.
- Cluster 2 with nodes X, Y and Z.
The idea of JBCACHE-816 is to enable inter cluster or data centre asynchronous replication of data.
This service would be a singleton running in the coordinators of the the clusters that we're interconnecting.
For this case, assume coord for C1 is A and coord for C2 is X.
Both A and X start a new JGroups communication channel to pass each other node modification or
removal messages. The service is based around cache listeners where they listen to cache
modifications notifications and send it to the other node. For example:
User puts data in A. Listener in A catches that, takes the modification and sends it over the JGroups channel
to X which in turn needs to replicate it to the C2. To do that, it currently uses Cache API, so X calls put(...) on
the cache.
I'd like to make communications be both way to give much greater flexibility to the solution, so when X calls
put(...) on the cache, it'll also receive notifications so you basically end up in an endless ping pong effect.
The idea is for this put() call not to generate event notifications locally to avoid this ping pong effect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months