[JBoss JIRA] Created: (JBCACHE-1406) issue with removing an node in tx
by Mircea Markus (JIRA)
issue with removing an node in tx
---------------------------------
Key: JBCACHE-1406
URL: https://jira.jboss.org/jira/browse/JBCACHE-1406
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP9
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 1.4.X
tx.start()'
cache.put(/a/b/c);
cache.remove(/a/b);
cache.put(/a/b/d);
tx.commit();
assert "this still exists in the internal structure" : cache.peek(/a/b/c) == null;
above assertion fails.
The problem is that when tx commits and cache wants to remove /a/b, sees that its not marked for removal (as it was re-added through put(/a/b/d) )and does not look in its children.
Method is TreeCache.realRemove, and it;s called from TxInterceptor.commit()
UT added to reproduce the issue is: org.jboss.cache.RemoveOnTxTest.
--
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, 4 months
[JBoss JIRA] Created: (JBCACHE-1412) TreeCacheMarshaller140 marshalling replaces distinct but equal() objects
by Brian Stansberry (JIRA)
TreeCacheMarshaller140 marshalling replaces distinct but equal() objects
------------------------------------------------------------------------
Key: JBCACHE-1412
URL: https://jira.jboss.org/jira/browse/JBCACHE-1412
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Replication
Affects Versions: 1.4.1.SP9
Reporter: Brian Stansberry
Assignee: Manik Surtani
Priority: Critical
The marshalling logic in TreeCacheMarshaller140 uses a HashMap as store of objects already written so it can replace subsequent writes of the same object with a magic number. Use of a HashMap is incorrect, as magic number replacement should only occur if an object with the same identity is detected, not one that just satisfies equals() but not ==.
Either a custom map that uses System.identityHashCode() for hashing and == instead of equals() for equality is needed, or the map key should be System.identityHashCode(). Note the Object.hashCode() javadocs do not absolutely guarantee uniqueness in System.identityHashCode(), so a custom map is probably better:
"As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)"
Non-uniquenesss in System.identityHashCode() might be more of an issue in systems with large heaps that can't be addressed with 32 bits.
--
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, 4 months
Jboss-cache error
by Meena Rajani
Hi
I am new to jboss cahe, could you please help me in sorting out this error.
I am using netbeans to compile my program running it on remote linux server.
NetBeans 6.0.1
JDK jdk1.5.0_12
JRE jre1.6.0_07
JBossCache-1.4.0.SP1
POstgreSQL 8.3
postgresql-8.2-506.jdbc3 driver
Running Windows XP
1- While compilin Jboss-Cache I am getting following error , though it is building successfuly
Created dir: C:\Documents and Settings\Meena\Desktop\db project\jboss-cache\build\classesCompiling 258 source files to C:\Documents and Settings\Meena\Desktop\db project\jboss-cache\build\classesC:\Documents and Settings\Meena\Desktop\db project\jboss-cache\src\org\jboss\cache\aop\TreeCacheAopDelegate.java:127: warning: non-varargs call of varargs method with inexact argument type for last parameter;cast to java.lang.Class for a varargs callcast to java.lang.Class[] for a non-varargs call and to suppress this warning Constructor ctr = clazz.getDeclaredConstructor(null);C:\Documents and Settings\Meena\Desktop\db project\jboss-cache\src\org\jboss\cache\aop\TreeCacheAopDelegate.java:129: warning: non-varargs call of varargs method with inexact argument type for last parameter;cast to java.lang.Object for a varargs callcast to java.lang.Object[] for a non-varargs call and to suppress this warning obj = ctr.newInstance(null);Note: Some input files use or override a deprecated API.Note: Recompile with -Xlint:deprecation for details.Note: Some input files use unchecked or unsafe operations.Note: Recompile with -Xlint:unchecked for details.2 warnings
While Running the compiled code it on Server
I am getting following error
It seems it canot not initialize cache, complaining about configuration file. I tried the same code few months ago it was working fine.
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:585) at org.jboss.cache.PropertyConfigurator.configure(PropertyConfigurator.java:215) at org.jboss.cache.PropertyConfigurator.configure(PropertyConfigurator.java:161) at org.usyd.sit.perfEvalServer.ServerImpl.initCache(ServerImpl.java:60) at org.usyd.sit.perfEvalServer.ServerImpl.<init>(ServerImpl.java:45) at org.usyd.sit.perfEvalServer.ServerImpl.main(ServerImpl.java:150)Caused by: java.lang.IllegalArgumentException: setCacheMode(): caching mode -1 is invalid at org.jboss.cache.TreeCache.setCacheMode(TreeCache.java:928) at org.jboss.cache.TreeCache.setCacheMode(TreeCache.java:909) ... 9 moreorg.jboss.cache.ConfigureException: configure(): can't invoke setCacheMode to configure TreeCache properties. Exception: java.lang.reflect.InvocationTargetException at org.jboss.cache.PropertyConfigurator.configure(PropertyConfigurator.java:220) at org.jboss.cache.PropertyConfigurator.configure(PropertyConfigurator.java:161) at org.usyd.sit.perfEvalServer.ServerImpl.initCache(ServerImpl.java:60) at org.usyd.sit.perfEvalServer.ServerImpl.<init>(ServerImpl.java:45) at org.usyd.sit.perfEvalServer.ServerImpl.main(ServerImpl.java:150)
Following is my xml file
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== --><!-- --><!-- Sample TreeCache Service Configuration --><!-- --><!-- ===================================================================== -->
<server>
<classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
<!-- ==================================================================== --> <!-- Defines TreeCache configuration --> <!-- ==================================================================== -->
<mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache">
<depends>jboss:service=Naming</depends> <depends>jboss:service=TransactionManager</depends>
<!-- Configure the TransactionManager --> <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
<!-- Isolation level : SERIALIZABLE REPEATABLE_READ (default) READ_COMMITTED READ_UNCOMMITTED NONE --> <attribute name ="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL REPL_ASYNC REPL_SYNC INVALIDATION_ASYNC INVALIDATION_SYNC FRESHNESS_ASYNC FRESHNESS_GROUP_ASYNC INVALIDATION_FINEGRAIN --> <attribute name="CacheMode">FRESHNESS_ASYNC</attribute>
<!-- Freshness limit, in ms --> <attribute name="FreshnessLimit">1000</attribute>
<!-- Just used for async repl: use a replication queue --> <attribute name="UseReplQueue">false</attribute>
<!-- Replication interval for replication queue (in ms) --> <attribute name="ReplQueueInterval">0</attribute>
<!-- Max number of elements which trigger replication --> <attribute name="ReplQueueMaxElements">0</attribute>
<!-- Name of cluster. Needs to be the same for all clusters, in order to find each other --> <attribute name="ClusterName">TreeCache-Cluster</attribute>
<!-- JGroups protocol stack properties. Can also be a URL, e.g. file:/home/bela/default.xml <attribute name="ClusterProperties"></attribute> -->
<attribute name="ClusterConfig"> <config> <!-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address --> <!-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true --> <UDP mcast_addr="228.1.2.3" mcast_port="48866" bind_addr="129.78.97.10" ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000" ucast_recv_buf_size="80000" loopback="false"/> <PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false"/> <MERGE2 min_interval="10000" max_interval="20000"/> <!-- <FD shun="true" up_thread="true" down_thread="true" />--> <FD_SOCK/> <VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/> <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192" up_thread="false" down_thread="false"/> <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false"/> <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false"/> <FRAG frag_size="8192" down_thread="false" up_thread="false"/> <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true"/> <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/> </config> </attribute>
<!-- Whether or not to fetch state on joining a cluster NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive. --> <attribute name="FetchInMemoryState">true</attribute>
<!-- The max amount of time (in milliseconds) we wait until the initial state (ie. the contents of the cache) are retrieved from existing members in a clustered environment --> <attribute name="InitialStateRetrievalTimeout">20000</attribute>
<!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> <attribute name="SyncReplTimeout">20000</attribute>
<!--<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>-->
<!-- Max number of milliseconds to wait for a lock acquisition --> <attribute name="LockAcquisitionTimeout">15000</attribute>
<!-- Name of the eviction policy class. --> <attribute name="EvictionPolicyClass"></attribute>
<!-- Indicate whether to use region based marshalling or not. Set this to true if you are running under a scoped class loader, e.g., inside an application server. Default is "false". --> <attribute name="UseRegionBasedMarshalling">false</attribute> </mbean></server>
Thanks
Meena
_________________________________________________________________
Connect to the next generation of MSN Messenger
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&sourc...
15 years, 6 months
[JBoss JIRA] Created: (JBCACHE-1429) CacheStatus shouldn't WARN if recursive call made to isXXXAllowed()
by Brian Stansberry (JIRA)
CacheStatus shouldn't WARN if recursive call made to isXXXAllowed()
-------------------------------------------------------------------
Key: JBCACHE-1429
URL: https://jira.jboss.org/jira/browse/JBCACHE-1429
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.0.CR1, 2.2.1.CR2
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 2.2.1.GA, 3.0.0.GA
For example, isStopAllowed() shouldn't warn if current state is STOPPING. It's easy for a CacheJmxWrapper to end up triggering a call to that method while the cache is stopping; happens all the time in the AS, resulting in spurious WARN logs. Such a call is a normal reentrance check and should be logged at DEBUG; WARN should be reserved for truly odd stuff like calling isStopAllowed() while CREATING, which likely indicates a coding 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, 6 months
[JBoss JIRA] Created: (JBCACHE-1428) Remove per-request DEBUG logging
by Brian Stansberry (JIRA)
Remove per-request DEBUG logging
--------------------------------
Key: JBCACHE-1428
URL: https://jira.jboss.org/jira/browse/JBCACHE-1428
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.2.1.CR2
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 2.2.1.GA
Switch to TRACE:
2008-10-15 14:37:00,271 DEBUG [org.jboss.cache.transaction.DummyTransaction] (http-10.18.94.176-8080-1) processing beforeCompletion for org.jboss.cache.pojo.interceptors.PojoTxSynchronizationHandler@1a569f0
2008-10-15 14:37:00,271 DEBUG [org.jboss.cache.transaction.DummyTransaction] (http-10.18.94.176-8080-1) processing beforeCompletion for tx=org.jboss.cache.transaction.DummyTransaction@13510945, handlers=[TxInterceptor.LocalSynchronizationHandler(gtx=GlobalTransaction:<10.18.94.176:48641>:1, tx=org.jboss.cache.transaction.DummyTransaction@13510945)]
2008-10-15 14:37:00,272 DEBUG [org.jboss.cache.transaction.DummyTransaction] (http-10.18.94.176-8080-1) processing afterCompletion for org.jboss.cache.pojo.interceptors.PojoTxSynchronizationHandler@1a569f0
2008-10-15 14:37:00,272 DEBUG [org.jboss.cache.transaction.DummyTransaction] (http-10.18.94.176-8080-1) processing afterCompletion for tx=org.jboss.cache.transaction.DummyTransaction@13510945, handlers=[TxInterceptor.LocalSynchronizationHandler(gtx=GlobalTransaction:<10.18.94.176:48641>:1, tx=org.jboss.cache.transaction.DummyTransaction@13510945)]
2008-10-15 14:37:00,272 DEBUG [org.jboss.cache.interceptors.TxInterceptor] (http-10.18.94.176-8080-1) Running commit phase. One phase? true
2008-10-15 14:37:00,288 DEBUG [org.jboss.cache.interceptors.TxInterceptor] (http-10.18.94.176-8080-1) Finished local commit/rollback method for GlobalTransaction:<10.18.94.176:48641>:1
2008-10-15 14:37:00,288 DEBUG [org.jboss.cache.interceptors.TxInterceptor] (http-10.18.94.176-8080-1) Finished commit phase
--
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, 6 months
[JBoss JIRA] Created: (JBCACHE-1424) JDBCCacheLoader does not close ConnectionFactory
by Krzysztof Sobolewski (JIRA)
JDBCCacheLoader does not close ConnectionFactory
------------------------------------------------
Key: JBCACHE-1424
URL: https://jira.jboss.org/jira/browse/JBCACHE-1424
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: AdjListJDBCCacheLoader.java.patch
Maybe I don't understand something, but I think this is a bug that the method AdjListJDBCCacheLoader.stop() closes the ConnectionFactory only if the config.getDropTable() option is set to true. I don't want to drop my table, but I want to close the ConnectionFactory (because C3P0 won't unregister itself and I get a MBean leak after restart of my component).
My guess is that the try block was misplaced.
--
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, 6 months