[JBossCache] - Jboss Caching issue
by bhavranjan
Hi All,
I am using Jboss Cache
i have configured the Configuration file as follows
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Sample TreeCache Service Configuration -->
<!-- -->
<!-- ===================================================================== -->
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
jboss:service=Naming
jboss:service=TransactionManager
<!--
Configure the TransactionManager
-->
org.jboss.cache.JBossTransactionManagerLookup
<!--
Node locking level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
REPEATABLE_READ
<!--
Valid modes are LOCAL
REPL_ASYNC
REPL_SYNC
INVALIDATION_ASYNC
INVALIDATION_SYNC
-->
LOCAL
<!-- New 1.3.x cache loader config block -->
<!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
false
/a/b, /allTempObjects, /some/specific/fqn,/demo
false
<!-- we can now have multiple cache loaders, which get chained -->
org.jboss.cache.loader.FileCacheLoader
<!-- same as the old CacheLoaderConfig attribute -->
location=/tmp/bhavFileStore
<!-- only one cache loader in the chain may set fetchPersistentState to true.
An exception is thrown if more than one cache loader sets this to true. -->
true
<!-- determines whether this cache loader ignores writes - defaults to false. -->
false
<!-- if set to true, purges the contents of this cache loader when the cache starts up.
Defaults to false. -->
false
<!--
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
-->
20000
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
15000
<!-- Max number of milliseconds to wait for a lock acquisition -->
10000
<!-- Name of the eviction policy class. Not supported now. -->
-------------------------------------------------------
Configuration for binding with JNDI
------------------------------------------------------
jboss:service=invoker,type=jrmp
jboss.cache:service=TreeCache
TreeCache true org.jboss.cache.TreeCacheMBean
org.jboss.proxy.ClientMethodInterceptor
org.jboss.proxy.SecurityInterceptor
org.jboss.invocation.InvokerInterceptor
jboss:service=invoker,type=jrmp
jboss.cache:service=TreeCache
I have two wars and no EAR. Second WAR is retrieving a string value stored in Cache by first WAR.
But when i start the server it gives error:
rg.jboss.deployment.DeploymentException: Class does not expose a management interface: java.lang.Object; - nested throwable: (javax.management.NotCompliantMBeanException: Class does not expose a management interface: java.lang.Object)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Unknown Source)
and
--- Incompletely deployed packages ---
org.jboss.deployment.DeploymentInfo@d562c17c { url=file:/D:/jboss-4.0.5.GA/server/default/deploy/tree-service.xml }
deployer: org.jboss.deployment.SARDeployer@5a67c9
status: Deployment FAILED reason: Class does not expose a management interface: java.lang.Object; - nested throwable: (javax.management.NotCompliantMBeanException: Class does not expose a management interface: java.lang.Object)
state: FAILED
watch: file:/D:/jboss-4.0.5.GA/server/default/deploy/tree-service.xml
altDD: null
lastDeployed: 1170235288122
lastModified: 1170235288107
mbeans:
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008706#4008706
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008706
19 years, 2 months
[JBoss Seam] - java.lang.StackOverflowError when running seam generate-enti
by christian_zeidler
Hello!
I tried to run a basic database model through the reverse enginering tool that comes with seam gen and I am getting a java.lang.StackOverflowError without any details.
Here is the output from running seam generate-entities (working with a configured project that works fine when running generate-entities with other tables):
| Buildfile: F:\jboss\jboss-seam-1.1.0.GA\seam-gen\build.xml
|
| validate-workspace:
|
| validate-project:
|
| generate-entities:
| [hibernate] Executing Hibernate Tool with a JDBC Configuration (for reverse engineering)
| [hibernate] 1. task: hbm2java (Generates a set of .java files)
| [hibernate] 30.01.2007 19:01:04 org.hibernate.cfg.Environment <clinit>
| [hibernate] INFO: Hibernate 3.2 cr4
| [hibernate] 30.01.2007 19:01:04 org.hibernate.cfg.Environment <clinit>
| [hibernate] INFO: hibernate.properties not found
| [hibernate] 30.01.2007 19:01:04 org.hibernate.cfg.Environment buildBytecodeProvider
| [hibernate] INFO: Bytecode provider name : cglib
| [hibernate] 30.01.2007 19:01:04 org.hibernate.cfg.Environment <clinit>
| [hibernate] INFO: using JDK 1.4 java.sql.Timestamp handling
| [hibernate] 30.01.2007 19:01:05 org.hibernate.connection.DriverManagerConnectionProvider configure
| [hibernate] INFO: Using Hibernate built-in connection pool (not for production use!)
| [hibernate] 30.01.2007 19:01:05 org.hibernate.connection.DriverManagerConnectionProvider configure
| [hibernate] INFO: Hibernate connection pool size: 20
| [hibernate] 30.01.2007 19:01:05 org.hibernate.connection.DriverManagerConnectionProvider configure
| [hibernate] INFO: autocommit mode: false
| [hibernate] 30.01.2007 19:01:05 org.hibernate.connection.DriverManagerConnectionProvider configure
| [hibernate] INFO: using driver: com.mysql.jdbc.Driver at URL: jdbc:mysql:///****
| [hibernate] 30.01.2007 19:01:05 org.hibernate.connection.DriverManagerConnectionProvider configure
| [hibernate] INFO: connection properties: {user=----, password=****}
| [hibernate] 30.01.2007 19:01:06 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: RDBMS: MySQL, version: 5.0.27-community-nt
| [hibernate] 30.01.2007 19:01:06 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-5.0.4 ( $Date: 2006-10-19 17:47:48 +0200 (Thu, 19 Oct 2006) $, $Revision
| : 5908 $ )
| [hibernate] 30.01.2007 19:01:07 org.hibernate.dialect.Dialect <init>
| [hibernate] INFO: Using dialect: org.hibernate.dialect.MySQLDialect
| [hibernate] 30.01.2007 19:01:07 org.hibernate.transaction.TransactionFactoryFactory buildTransactionFactory
| [hibernate] INFO: Using default transaction strategy (direct JDBC transactions)
| [hibernate] 30.01.2007 19:01:07 org.hibernate.transaction.TransactionManagerLookupFactory getTransactionManagerLookup
| [hibernate] INFO: No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Automatic flush during beforeCompletion(): disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Automatic session close at end of transaction: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: JDBC batch size: 15
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: JDBC batch updates for versioned data: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Scrollable result sets: enabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: JDBC3 getGeneratedKeys(): enabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Connection release mode: auto
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Maximum outer join fetch depth: 2
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Default batch fetch size: 1
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Generate SQL with comments: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Order SQL updates by primary key: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory createQueryTranslatorFactory
| [hibernate] INFO: Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
| [hibernate] 30.01.2007 19:01:07 org.hibernate.hql.ast.ASTQueryTranslatorFactory <init>
| [hibernate] INFO: Using ASTQueryTranslatorFactory
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Query language substitutions: {}
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: JPA-QL strict compliance: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Second-level cache: enabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Query cache: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory createCacheProvider
| [hibernate] INFO: Cache provider: org.hibernate.cache.NoCacheProvider
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Optimize cache for minimal puts: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Structured second-level cache entries: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Statistics: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Deleted entity synthetic identifier rollback: disabled
| [hibernate] 30.01.2007 19:01:07 org.hibernate.cfg.SettingsFactory buildSettings
| [hibernate] INFO: Default entity-mode: pojo
| [hibernate] 30.01.2007 19:01:08 org.hibernate.connection.DriverManagerConnectionProvider close
| [hibernate] INFO: cleaning up connection pool: jdbc:mysql:///****
| [hibernate] 30.01.2007 19:01:08 org.hibernate.tool.Version <clinit>
| [hibernate] INFO: Hibernate Tools 3.2.0.snapshotb9
| 30.01.2007 19:01:09 org.hibernate.connection.DriverManagerConnectionProvider close
| INFO: cleaning up connection pool: jdbc:mysql:///****
| [hibernate] 2. task: generic exportertemplate: view/list.xhtml.ftl
| [hibernate] 3. task: generic exportertemplate: view/view.xhtml.ftl
| [hibernate] 4. task: generic exportertemplate: view/edit.page.xml.ftl
|
| BUILD FAILED
| java.lang.StackOverflowError
|
| Total time: 13 seconds
|
I was able to narrow it down to the use of a foreign key constraint referencing to the same table. Here is an example:
| DROP TABLE IF EXISTS `people`;
| CREATE TABLE `people` (
| `id` bigint NOT NULL,
| `given_name` varchar(20) NOT NULL default '0',
| `name` varchar(20) NOT NULL,
| `fk_likes_person` bigint default NULL,
| PRIMARY KEY (`id`),
| FOREIGN KEY (fk_likes_person) REFERENCES people(id) ON DELETE NO ACTION
| ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
|
According to MySQL Documentation this is possible with InnoDB tables
anonymous wrote :
| ...Note that InnoDB supports foreign key references within a table. In these cases, "child table records" really refers to dependent records within the same table...
|
Is there a good reason for this behaviour? If you consider this as a bug, please point me to the right place for reporting it.
- Christian
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008705#4008705
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008705
19 years, 2 months
[EJB 3.0] - JBoss cache tuning with RC9 patch 1, cluster and Optimistic
by J.Hedin
Hi
We use JBoss 4.0.5.GA + EJB3 RC9 patch 1 + JBoss Cache 1.4.1.GA in a cluster with two nodes. All our entity EJBs are Optimistic locked via @Version. However, the cache looks like it uses pessimistic locks during the whole transaction. Is the JBoss Cache in conflict with the @Version annotation? How should I tune the JBoss cache? I would like to set
locking: OPTIMISTIC
replication: INVALID_SYNC
is that safe with EJB3 entities?
My persistence.xml
| <?xml version="1.0" encoding="UTF-8"?>
| <!-- $Id: persistence.xml,v 1.3 2006/06/27 15:07:45 johan Exp $ -->
| <persistence>
| <persistence-unit name="IBCS">
| <jta-data-source>java:/IBDS</jta-data-source>
| <properties>
| <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLInnoDBDialect"/>
| <property name="hibernate.hbm2ddl.auto" value="none"/>
| <property name="hibernate.cache.provider_class" value="org.jboss.ejb3.entity.TreeCacheProviderHook"/>
| <property name="hibernate.treecache.mbean.object_name" value="jboss.cache:service=EJB3EntityTreeCache"/>
| </properties>
| </persistence-unit>
| </persistence>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008701#4008701
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008701
19 years, 2 months
[JBossCache] - Re: Performance expectations
by mvlior
Hi,
Thanks for replying; please see inline.
anonymous wrote : There are many differences in what you tested and the wiki page.
|
| Mainly, they were testing field updates on attached objects across a cluster. And you are just testing the speed of attaching objects.
|
Yes, you are right, they are different. In fact, the expectations from our test are based on the wiki's results for the cases named "TreeCache" and "100-0 PojoCache". Unless they were totally misinterpreted, then even a very cautious estimate for the throughput would be, in my opinion, about 1500 "different POJO attachment" per second.
At no point in the stress does the throughput go above a quarter of that figure.
It should also be noted that no network traffic / local replication efforts are involved in our case since there is only one local cache.
anonymous wrote : If your objects are simple strings, just use the plain TreeCache.
Actually, the system's needs are for more complex POJOs. Attaching small String objects was chosen for the stress test because:
1. They are small objects, so throughput is expected to be high, and
2. Strings are not aspectized, so this test can be run by other people without the need to run aopc on our classes.
I guess that at the end of the day, the question is how fast this code is supposed to run, given that environment.
Our hope is that perhaps something can be done to increase the throughput to a level acceptable for our system.
Thanks for reading,
Lior Neuman
R&D Team
MailVision LTD
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008699#4008699
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008699
19 years, 2 months