JBossCache 1.2.4 beta is available

[ben.wang]

As titled. You can download it from:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=356087

Full details of the Jira issues can be found on jira.jboss.com. I will try to blog about the key features in this release.

Here is the changelog.txt that is included in the dist. Please report any problem here.


Release 1.2.4Beta (Spet 12 2005)
===========================

* New object graph model for JBossCacheAop to handle complex
interactions between Collections and Pojos.
* Added jboss-cache-minimal-dist.zip for library only
* ExtendedTreeCacheListener for additional TreeCache events
* Upgraded to JBossAop 1.3.1 libraries
* JBossCacheAop load-time instrumentation mode uses a new class loader
* Added passivation/activation
* Added a TreeCacheMarshaller to handle scoped class loader
* Added an additional Api findObjects for TreeCacheAop
* JBossCacheAop object graph now works with persistency
* Added 2 network management test cases under org.jboss.cache.aop.integrated
packages
* Renamed previously examples directory to tests. Examples directory now
has complete examples
* Collection classes when detached from cache will now automatically
populate the values from cache to in-memory
* TreeCacheAop loadtime instrumentation use a GeneratedInstrumentClassLoader
now
* TreeCacheAop new doc
* Test package has been renamed to mirror class being tested

Details

** Feature Request
* [JBCACHE-12] - Async CacheLoader
* [JBCACHE-66] - Passivation/overflow
* [JBCACHE-87] - Add an abstract implementation of TreeCacheListener
* [JBCACHE-104] - Mass removal of AOP POJOs
* [JBCACHE-159] - preEvict and preRemove would be useful
* [JBCACHE-196] - Upgrade to Sleepycat 2.0
* [JBCACHE-205] - Added a new API to query all the existing pojos in TreeCacheAop
* [JBCACHE-223] - CacheLoader in cacheaop support object relationship
* [JBCACHE-246] - Should allow to overwrite existing Pojo if it is not multipled referenced
* [JBCACHE-255] - Create a marshalling handler for TreeCache
* [JBCACHE-265] - Create build examples for load and compile time instrumentation for JBossCacheAop
* [JBCACHE-273] - Support partial state transfer
* [JBCACHE-287] - Create individual example completed with Ant script for ship in the distribution

** Bug
* [JBCACHE-116] - CacheLoaderInterceptor calls CacheLoader.exists() spuriously
* [JBCACHE-127] - Binding JBossCache 1.2.1 using JRMPProxyFactory to JNDI
* [JBCACHE-135] - Node eviction in AopTree causes permanent removal of a node
* [JBCACHE-178] - removeObject needs to remove remote node's cacheinterceptor in TreeCacheAop
* [JBCACHE-184] - Error in capacity warning calculation in Region.putNodeEvent
* [JBCACHE-185] - JBossCacheAop getObject call will trigger un-necessary network replication
* [JBCACHE-191] - replication_granularity is not specified in jboss-web_4_0.dtd (and 3_2)
* [JBCACHE-192] - Nodes don't get unlocked in special cases after method calls
* [JBCACHE-200] - Initial state transfer produces class not serializable error in TreeCacheAop
* [JBCACHE-216] - Should throw exception when default region is not configured in LRUPolicy config
* [JBCACHE-221] - Shared objects under Collection throws exception
* [JBCACHE-228] - Collection class removeObject should return the old copy
* [JBCACHE-243] - Incorrect Iterator impl in Collection List and Set proxies
* [JBCACHE-253] - Missing Modify Notification if an object is removed from a node
* [JBCACHE-260] - Jboss Cache IdentityLock read/write lock could not be acquired
* [JBCACHE-277] - PassivationInterceptor fails when used with a tx started outside of calls to the cache.
* [JBCACHE-280] - nodeCreated() callback leads to leftover locks when calling back into the cache (get(), put())
* [JBCACHE-284] - Node.put() does not result in replication

** Task
* [JBCACHE-148] - null obj arguement will throw exception in putObject
* [JBCACHE-164] - TreeCacheAop eviction is allowed only with CacheLoader
* [JBCACHE-179] - refactoring removeObject
* [JBCACHE-183] - Over synchronization in IdentityLock and LockMap
* [JBCACHE-186] - Replace synchronizedSet/List() with ConcurrentHashMap
* [JBCACHE-187] - Inefficient create_lock in LockInterceptor.lock()
* [JBCACHE-188] - Replace TreeCacheListener Vector with more concurrent equivalent
* [JBCACHE-189] - Cache hash code for Fqn and GlobalTransaction objects
* [JBCACHE-190] - Reduce frequency of calls to nodeEventQueue_.size() in Region.putNodeEvent
* [JBCACHE-193] - ReadWriteLockWithUpgrade concurrency problem due to ThreadLocal
* [JBCACHE-195] - Change LockMap.readOwnersList_ to ConcurrentReaderHashMap from ConcurrentHashMap
* [JBCACHE-202] - Custom Eviction Policy: Use age of items to determine eviction order
* [JBCACHE-211] - faq update
* [JBCACHE-212] - Doc update
* [JBCACHE-217] - Refactor test class package structure to mirror the class being tested...
* [JBCACHE-219] - Renamed key of sub-object that is Serializable but not Aspectized
* [JBCACHE-220] - Handle multiple references/object graph for Collection classes
* [JBCACHE-222] - Internal fqn name for Collection class may not be unique
* [JBCACHE-244] - Refactor JBossCacheAop object graph model
* [JBCACHE-247] - AOPInstance has a sourceFqn set to track referees
* [JBCACHE-248] - New integrated junit tests need to run using annoc target
* [JBCACHE-249] - Multiple distribution packages
* [JBCACHE-261] - Distributed State (TreeCache) requirement for TreeCache listener
* [JBCACHE-263] - Upgraded to JBossAop 1.3 libraries
* [JBCACHE-264] - Refactored startService lifecycle
* [JBCACHE-271] - Validate AbstractTreeCacheListener implementation
* [JBCACHE-272] - Update doc and faq for JBCACHE-87, JBCACHE-159, JBCACHE-229
* [JBCACHE-275] - JRunit Tests should be moved to /perf sourcetree
* [JBCACHE-276] - Create a distributed rpc functionality in JBossCache layer
* [JBCACHE-278] - Supported Collection classes with non-primitive key
* [JBCACHE-282] - use object.toString to construct the relative fqn in Collections mapping

[xavierpayne2]

Heya does the Optimistic Locking stuff work when using JBossCache as an MBean within JBoss 4.0.2.

I tried dropping jboss-cache.jar into my lib directory (overwriting the old one) and adding the attribute:

<attribute name="NodeLockingScheme">OPTIMISTIC</attribute>

to my caches service.xml. Now I get the following exception:

org.jboss.deployment.DeploymentException: No Attribute found with name: NodeLockingScheme
 at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:263)
 at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:164)
 at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:118)
 at org.jboss.system.ServiceController.install(ServiceController.java:202)
 at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy4.install(Unknown Source)

I was hoping to test and re-bench our JBoss 4.0.2 cluster configuration here as it uses 4 seperate jboss caches (three of them replicate across the cluster and one of those three is ASYNC.) So its a pretty good test of most of the the jboss cache fuctionality.

[brian.stansberry]

Optimistic Locking is not in 1.2.4. It's on the roadmap for 1.3 (the next planned release).

[xavierpayne2]

Alrighty. I was just going to give it a go because the notes from the download page:

http://jira.jboss.com/jira/secure/ReleaseNote.jspa?projectId=10051&styleName=Html&version=12310238

said it was in there in "beta" form so I thought I'd check it out and provide feedback.

[brian.stansberry]

I apologize; you're right; it's listed in the online release notes (although the comments in the related JIRA issues show optimistic locking is only there in "alpha" form -- the JBossCache release is BETA, but not this feature).

The problem you're having is the NodeLockingScheme getter/setter were added to TreeCache, but not to the TreeCacheMBean interface. I expect we didn't see this in unit tests as the tests operated on the TreeCache directly, not via the interface.

Thanks for pointing this out!

[belaban]

Let's fix this immediately. Manik, do we have other methods which should be accessible via JMX ?
I'm not sure though if this warrants a new release (1.2.4-patch1), because the O/L code is not officially supported until 1.3...
Suggestions ?

[belaban]

we'll fix it, for now just add the getter and setter to TreeCacheMBean and recompile

[xavierpayne2]

Alrighty I'll grab the latest cvs source and compile it with the modified MBean interface and give it a go.

Even as alpha I wouldn't mind checking it out. I don't plan to put it into production I really just want to try it out and give you guys some feedback. JBossCache saved us a ton of time when we decided to make our architecture clusterable. Currently it's pretty much the backbone of our project.

I need to dig up the link to the Jira where you guys were soliciting feedback for the new version. I have lots of input I'd like to contribute based on our experiences with JBossCache over the past year I just didn't have the time earlier this month to capture and post them.

[belaban]

http://jira.jboss.com/jira/browse/JBCACHE. Just make sure you don't use JIRA to ask questions, really just to post bug reports. But I'm sure you knew that :-)
Cheers,
Bela

[xavierpayne2]

Found another potential problem with running the MBean inside of JBoss... When using a JDBC CacheLoader it seems to be trying to work with the datasource before its ready even though I have specified a dependancy on the datasource.

I checked the constructor for TreeCache and I don't see anything there that would be a problem. Constructors are the only thing I am aware of in an MBean that gets called regardless of dependancies. I drop the original jboss-cache.jar back in and jboss starts up just fine...

Below is the stack trace I am getting on start up and the service.xml I am using. Notice I have commented out the optimistic locking and the new "UseMarshalling" settings and the problem still occurs.

service.xml:

<mbean code="org.jboss.cache.TreeCache"
 name="jboss.cache:service=TreeCachePersisted">

 <depends>jboss:service=Naming</depends>
 <depends>jboss:service=TransactionManager</depends>
 <depends>jboss.jca:service=DataSourceBinding,name=persistedCacheMySqlDS</depends>

 <!--
 Configure the TransactionManager
 -->
 <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>

 <!--
 Node locking scheme:
 OPTIMISTIC
 PESSIMISTIC (default)

 See http://wiki.jboss.org/wiki/Wiki.jsp?page=OptimisticNodeLocking for a discussion on this

 WARNING: Using node locking scheme of OPTIMISTIC is EXPERIMENTAL at this stage
 and is not officially released or supported.

 Use at your own risk (but do provide feedback on
 http://jira.jboss.com/jira/browse/JBCACHE-69)

 - Manik Surtani ([e-mail])
 <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
 -->
 <!--
 Isolation level : SERIALIZABLE
 REPEATABLE_READ (default)
 READ_COMMITTED
 READ_UNCOMMITTED
 NONE
 -->
 <attribute name="IsolationLevel">REPEATABLE_READ</attribute>

 <!--
 Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
 -->
 <attribute name="CacheMode">REPL_SYNC</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">TreeCachePersisted-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 -->
 <!--DO NOT MOVE OR REMOVE THIS COMMENT USED FOR CONFIG-->
 <UDP mcast_addr="228.1.2.6" mcast_port="48899"
 ip_ttl="64" ip_mcast="true" bind_addr="127.0.0.1"
 mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
 ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
 loopback="true"/>

 <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
 -->
 <attribute name="FetchStateOnStartup">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">30000</attribute>

 <!--
 Number of milliseconds to wait until all responses for a
 synchronous call have been received.
 -->
 <attribute name="SyncReplTimeout">10000</attribute>

 <!-- Max number of milliseconds to wait for a lock acquisition -->
 <attribute name="LockAcquisitionTimeout">15000</attribute>


 <!-- Name of the eviction policy class. Not supported now. -->
 <attribute name="EvictionPolicyClass"></attribute>

 <!-- Configuration of the database persistence used for this cache. -->
 <attribute name="CacheLoaderClass">org.jboss.cache.loader.JDBCCacheLoader</attribute>
 <attribute name="CacheLoaderShared">true</attribute>
 <attribute name="CacheLoaderPreload">/</attribute>
 <attribute name="CacheLoaderFetchTransientState">false</attribute>
 <attribute name="CacheLoaderFetchPersistentState">false</attribute>
 <attribute name="CacheLoaderConfig">
 cache.jdbc.datasource=java:/persistedCacheMySqlDS
 cache.jdbc.table.drop=false
 </attribute>

 <!--
 Indicate whether to use 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="UseMarshalling">true</attribute>
 -->
 </mbean>

StackTrace:

14:20:09,877 ERROR [TreeCache] Initialization failed jboss.cache:service=TreeCachePersisted
java.lang.IllegalStateException: Failed to lookup datasource java:/persistedCacheMySqlDS: persistedCacheMySqlDS not bound
 at org.jboss.cache.loader.JDBCCacheLoader.setConfig(JDBCCacheLoader.java:130)
 at org.jboss.cache.TreeCache.createCacheLoader(TreeCache.java:1710)
 at org.jboss.cache.TreeCache._createService(TreeCache.java:1171)
 at org.jboss.cache.TreeCache.createService(TreeCache.java:1144)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:238)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:220)
 at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:897)
 at $Proxy0.create(Unknown Source)
 at org.jboss.system.ServiceController.create(ServiceController.java:330)
 at org.jboss.system.ServiceController.create(ServiceController.java:275)
 at org.jboss.system.ServiceController.create(ServiceController.java:353)
 at org.jboss.system.ServiceController.create(ServiceController.java:275)
 at org.jboss.system.ServiceController.create(ServiceController.java:353)
 at org.jboss.system.ServiceController.create(ServiceController.java:275)
 at org.jboss.system.ServiceController.create(ServiceController.java:353)
 at org.jboss.system.ServiceController.create(ServiceController.java:275)
 at org.jboss.system.ServiceController.create(ServiceController.java:353)
 at org.jboss.system.ServiceController.create(ServiceController.java:275)
 at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy4.create(Unknown Source)
 at org.jboss.deployment.SARDeployer.create(SARDeployer.java:229)
 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
 at $Proxy42.create(Unknown Source)
 at org.jboss.deployment.XSLSubDeployer.create(XSLSubDeployer.java:224)
 at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
 at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy8.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:501)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:277)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222)
 at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:897)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:418)
 at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy4.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:273)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:964)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
 at $Proxy5.deploy(Unknown Source)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:434)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:315)
 at org.jboss.Main.boot(Main.java:195)
 at org.jboss.Main$1.run(Main.java:463)
 at java.lang.Thread.run(Thread.java:595)

[brian.stansberry]

Hmm. The creation of the cache loader got moved from TreeCache.startService() to createService(). I'm speculating that the registration of the datasource with JNDI does not happen until the start phase, making it unavailable in the create phase.

I'll check it out. Thanks for the report.

[brian.stansberry]

See

http://jira.jboss.com/jira/browse/JBCACHE-303

[belaban]

This may be due to the fact that we try to lookup the datasource in create() rather than in start(). In create(), we cannot depend on other MBeans having been created (or initialized) yet.
Can you create a JIRA issue ?
Meantime, as a workaround, don't use a DS to configure JDBCCacheLoader, but specify the connection URL, uid/pwd etc directly.

[manik]

TreeCacheMBean getter and setter for NodeLockingScheme is in CVS - both in head and in JBossCache_1_2_4.

Cheers,
Manik

[rgrantitt]

I would like to download the jboss cache source code, however I haven't been able to find it. Where can I get a CVS account so that I may look into a JDBCCacheLoader.java Error I am getting.