Re: [JBoss-user] PersistenceManager wouldn't start
Hello once again, Adrian Brock wrote: On Thu, 2003-10-02 at 16:00, Stefan Puiu wrote: My previous mail seems to be Lost in Sourceforge, I provided the same link. Actually I wrote and sent my message before your first reply got to my inbox (let's call it the Sourceforge delay :) ), now I have them both. I had solved the problem partially and was eager to report the results :D. This is ok in 3.2.2, the destination manager now accepts a message cache attribute. It makes more sense this way around. The old style is still supported, but it can lead to circular dependencies. In 3.2.1 it only accepted CREATE_TABLES=true, in 3.2.2 it ignores the case in the comparison. The default is true, so just removing that property will work. Thanks for clarifying things, I thought the snippets were broken. Good thing to know, since anyway we're probably going to switch to 3.2.2 soon. Your hsqldb file is broken, if you are not using it any more you can delete it, it is in data/hsqldb Or just remove the hsqldb datasource deployment. Regards, Adrian I've removed the default.data and default.script files in data/hypersonic. So it's only used for the PersistenceManager? Removing it would be ok, since starting JBoss (default configuration) takes around one minute on Linux, anything that speeds up the process is ok with me. What can I say, thank you very much for your help, you've saved my day. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] PersistenceManager wouldn't start
On Thursday, Oct 2, 2003, at 17:29 Europe/Stockholm, Adrian Brock wrote: 17:52:18,059 INFO [MainDeployer] Starting deployment of package: file:/home/fane/builds/jboss-3.2.1/server/default/deploy/jms/jbossmq- service.xml JBossMQ uses HSQLDB as default. If You are not using the mq service then remove it or edit it to reflect Your chosen db settings. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] PersistenceManager wouldn't start
Hello list, I'm having trouble restarting JBoss (I'm using JBoss 3.2.1) after running some messaging tests that fail, the PersistenceManager throws an exception which gets thrown in the resolveAllUncomittedTXs method in org.jboss.mq.pm.jdbc2.PersistenceManager, as you can see in the stack trace attached. It seems to be Hypersonic SQL-related, the PersistenceManager can't connect to the hsql database. I haven't altered the configuration files in any way, I've just been running messaging tests that involve sending messages and synchronously receiving replies; the test class extends EJBTestCase from JUnitEJB, so it runs in the JBoss JVM, and because I used a synchronous receive() that wouldn't get any reply, that probably left an uncommitted transaction. How can I fix this? I promise I'll be a good boy and use receive(timeout) from now on :D... 15:12:24,402 INFO [TxConnectionManager] Started 15:12:24,402 INFO [PersistenceManager] Starting 15:12:30,819 ERROR [PersistenceManager] Starting failed org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.jboss.util.NestedSQLException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused))) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:276) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at org.jboss.system.ServiceController.start(ServiceController.java:408) at org.jboss.system.ServiceController.start(ServiceController.java:408) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:200) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:273) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) 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:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at
Re: [JBoss-user] PersistenceManager wouldn't start
There is a fundamental problem with the hsql mbean. When it starts, it creates a new thread to start the db. JBoss continues on to other services. If the thread takes too long to bind the sockets, you get Connection refused. Somebody hacked jdbc2 so you can do retries (default 5 times waiting 1.5 seconds on each attempt) attribute name=ConnectionRetryAttempts5/attribute Additionally, if you want to make sure the data is flushed to disk on every write, you should change the jdbc2 sql properties to use create cached table I wouldn't recommend using hsqldb for anything other than testing and demos. Regards, Adrian On Thu, 2003-10-02 at 13:42, Stefan Puiu wrote: Hello list, I'm having trouble restarting JBoss (I'm using JBoss 3.2.1) after running some messaging tests that fail, the PersistenceManager throws an exception which gets thrown in the resolveAllUncomittedTXs method in org.jboss.mq.pm.jdbc2.PersistenceManager, as you can see in the stack trace attached. It seems to be Hypersonic SQL-related, the PersistenceManager can't connect to the hsql database. I haven't altered the configuration files in any way, I've just been running messaging tests that involve sending messages and synchronously receiving replies; the test class extends EJBTestCase from JUnitEJB, so it runs in the JBoss JVM, and because I used a synchronous receive() that wouldn't get any reply, that probably left an uncommitted transaction. How can I fix this? I promise I'll be a good boy and use receive(timeout) from now on :D... __ 15:12:24,402 INFO [TxConnectionManager] Started 15:12:24,402 INFO [PersistenceManager] Starting 15:12:30,819 ERROR [PersistenceManager] Starting failed org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.jboss.util.NestedSQLException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused))) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:276) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at org.jboss.system.ServiceController.start(ServiceController.java:408) at org.jboss.system.ServiceController.start(ServiceController.java:408) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:476) at
Re: [JBoss-user] PersistenceManager wouldn't start
Hello Adrian and thanks for the reply, I'm using the PersistenceManager MBean configured out of the box to use HypersonicSQL by default, would defining a different datasource using, say, MySQL (let newDS be its name) and changing the PersistenceManager configuration to use that one solve the problem? Since PersistenceManager doesn't start neither does DestinationManager, so I can't run anything using JMS. So say I have a new-ds.xml file mapping to a java:/newDS datasource, would changing this entry in the PersistenceManager configuration be enough? depends optional-attribute-name=ConnectionManagerjboss.jca:service=Local TxCM,name=DefaultDS/depends to depends optional-attribute-name=ConnectionManagerjboss.jca:service=Local TxCM,name=newDS/depends About the jdbc2 hack, from what I read in the JBoss Administration Development Guide the default value for that attribute is 5 (excerpt from the part about configuring org.jboss.mq.pm.jdbc2.PersistenceManager): ConnectionRetryAttempts: An integer count used to allow the PM to retry attempts at getting a connection to the JDBC store. There is a 1500 millisecond delay between each connection failed connection attempt and the next attempt. This must be greater than or equal to 1 and defaults to 5. In my jbossmq-service.xml this isn't set, so I get it uses the default value of 5, so I gets I can't count on this as a solution. Adrian Brock wrote: There is a fundamental problem with the hsql mbean. When it starts, it creates a new thread to start the db. JBoss continues on to other services. If the thread takes too long to bind the sockets, you get Connection refused. Somebody hacked jdbc2 so you can do retries (default 5 times waiting 1.5 seconds on each attempt) attribute name=ConnectionRetryAttempts5/attribute Additionally, if you want to make sure the data is flushed to disk on every write, you should change the jdbc2 sql properties to use create cached table I wouldn't recommend using hsqldb for anything other than testing and demos. Regards, Adrian On Thu, 2003-10-02 at 13:42, Stefan Puiu wrote: Hello list, I'm having trouble restarting JBoss (I'm using JBoss 3.2.1) after running some messaging tests that fail, the PersistenceManager throws an exception which gets thrown in the resolveAllUncomittedTXs method in org.jboss.mq.pm.jdbc2.PersistenceManager, as you can see in the stack trace attached. It seems to be Hypersonic SQL-related, the PersistenceManager can't connect to the hsql database. I haven't altered the configuration files in any way, I've just been running messaging tests that involve sending messages and synchronously receiving replies; the test class extends EJBTestCase from JUnitEJB, so it runs in the JBoss JVM, and because I used a synchronous receive() that wouldn't get any reply, that probably left an uncommitted transaction. How can I fix this? I promise I'll be a good boy and use receive(timeout) from now on :D... __ 15:12:24,402 INFO [TxConnectionManager] Started 15:12:24,402 INFO [PersistenceManager] Starting 15:12:30,819 ERROR [PersistenceManager] Starting failed org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.jboss.util.NestedSQLException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused))) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:276) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at org.jboss.system.ServiceController.start(ServiceController.java:408) at org.jboss.system.ServiceController.start(ServiceController.java:408) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at
Re: [JBoss-user] PersistenceManager wouldn't start
With an external db, you won't see the same problem. The db is either started or it isn't. There are examples configurations coming with jboss-3.2.2 in docs/examples/jms for other dbs (I welcome contributions for other dbs not included). The sql properties should work with 3.2.x and 3.0.7+ Don't forget to change the mbean name of the db http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/etc/server/examples/deploy/ My guess is that is it taking longer than 5x1.5 = 7.5 seconds for hsqldb to recover its database log. Or it has failed to recover it altogether. :-( Regards, Adrian On Thu, 2003-10-02 at 15:03, Stefan Puiu wrote: Hello Adrian and thanks for the reply, I'm using the PersistenceManager MBean configured out of the box to use HypersonicSQL by default, would defining a different datasource using, say, MySQL (let newDS be its name) and changing the PersistenceManager configuration to use that one solve the problem? Since PersistenceManager doesn't start neither does DestinationManager, so I can't run anything using JMS. So say I have a new-ds.xml file mapping to a java:/newDS datasource, would changing this entry in the PersistenceManager configuration be enough? depends optional-attribute-name=ConnectionManagerjboss.jca:service=Local TxCM,name=DefaultDS/depends to depends optional-attribute-name=ConnectionManagerjboss.jca:service=Local TxCM,name=newDS/depends About the jdbc2 hack, from what I read in the JBoss Administration Development Guide the default value for that attribute is 5 (excerpt from the part about configuring org.jboss.mq.pm.jdbc2.PersistenceManager): ConnectionRetryAttempts: An integer count used to allow the PM to retry attempts at getting a connection to the JDBC store. There is a 1500 millisecond delay between each connection failed connection attempt and the next attempt. This must be greater than or equal to 1 and defaults to 5. In my jbossmq-service.xml this isn't set, so I get it uses the default value of 5, so I gets I can't count on this as a solution. Adrian Brock wrote: There is a fundamental problem with the hsql mbean. When it starts, it creates a new thread to start the db. JBoss continues on to other services. If the thread takes too long to bind the sockets, you get Connection refused. Somebody hacked jdbc2 so you can do retries (default 5 times waiting 1.5 seconds on each attempt) attribute name=ConnectionRetryAttempts5/attribute Additionally, if you want to make sure the data is flushed to disk on every write, you should change the jdbc2 sql properties to use create cached table I wouldn't recommend using hsqldb for anything other than testing and demos. Regards, Adrian On Thu, 2003-10-02 at 13:42, Stefan Puiu wrote: Hello list, I'm having trouble restarting JBoss (I'm using JBoss 3.2.1) after running some messaging tests that fail, the PersistenceManager throws an exception which gets thrown in the resolveAllUncomittedTXs method in org.jboss.mq.pm.jdbc2.PersistenceManager, as you can see in the stack trace attached. It seems to be Hypersonic SQL-related, the PersistenceManager can't connect to the hsql database. I haven't altered the configuration files in any way, I've just been running messaging tests that involve sending messages and synchronously receiving replies; the test class extends EJBTestCase from JUnitEJB, so it runs in the JBoss JVM, and because I used a synchronous receive() that wouldn't get any reply, that probably left an uncommitted transaction. How can I fix this? I promise I'll be a good boy and use receive(timeout) from now on :D... __ 15:12:24,402 INFO [TxConnectionManager] Started 15:12:24,402 INFO [PersistenceManager] Starting 15:12:30,819 ERROR [PersistenceManager] Starting failed org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.jboss.util.NestedSQLException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused))) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:276) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at
Re: [JBoss-user] PersistenceManager wouldn't start
Hello again, I've finally managed to make the PersistenceManager to work with MySQL, using the mysql-jdbc2.xml from this link which I've found searching the mailing list: http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/etc/server/examples/deploy/ There is an error in the mysql-jdbc2-ds.xml file though, the DestinationManager MBean doesn't have a MessageCache attribute, so using the snippets verbatim would cause an exception. Also, I had to manually create the database *and* the tables. On the other hand, even if things work now, I get a strange Hypersonic exception when starting JBoss, right when jms/jboss-service.xml gets deployed - I've included the stack trace in the attachment. Should I worry about it? Adrian Brock wrote: There is a fundamental problem with the hsql mbean. When it starts, it creates a new thread to start the db. JBoss continues on to other services. If the thread takes too long to bind the sockets, you get Connection refused. Somebody hacked jdbc2 so you can do retries (default 5 times waiting 1.5 seconds on each attempt) attribute name=ConnectionRetryAttempts5/attribute Additionally, if you want to make sure the data is flushed to disk on every write, you should change the jdbc2 sql properties to use create cached table I wouldn't recommend using hsqldb for anything other than testing and demos. Regards, Adrian On Thu, 2003-10-02 at 13:42, Stefan Puiu wrote: Hello list, I'm having trouble restarting JBoss (I'm using JBoss 3.2.1) after running some messaging tests that fail, the PersistenceManager throws an exception which gets thrown in the resolveAllUncomittedTXs method in org.jboss.mq.pm.jdbc2.PersistenceManager, as you can see in the stack trace attached. It seems to be Hypersonic SQL-related, the PersistenceManager can't connect to the hsql database. I haven't altered the configuration files in any way, I've just been running messaging tests that involve sending messages and synchronously receiving replies; the test class extends EJBTestCase from JUnitEJB, so it runs in the JBoss JVM, and because I used a synchronous receive() that wouldn't get any reply, that probably left an uncommitted transaction. How can I fix this? I promise I'll be a good boy and use receive(timeout) from now on :D... __ 15:12:24,402 INFO [TxConnectionManager] Started 15:12:24,402 INFO [PersistenceManager] Starting 15:12:30,819 ERROR [PersistenceManager] Starting failed org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.jboss.util.NestedSQLException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Connection is broken: Connection refused))) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:276) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at org.jboss.system.ServiceController.start(ServiceController.java:408) at org.jboss.system.ServiceController.start(ServiceController.java:408) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at
Re: [JBoss-user] PersistenceManager wouldn't start
On Thu, 2003-10-02 at 16:00, Stefan Puiu wrote: Hello again, I've finally managed to make the PersistenceManager to work with MySQL, using the mysql-jdbc2.xml from this link which I've found searching the mailing list: http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/etc/server/examples/deploy/ My previous mail seems to be Lost in Sourceforge, I provided the same link. There is an error in the mysql-jdbc2-ds.xml file though, the DestinationManager MBean doesn't have a MessageCache attribute, so using the snippets verbatim would cause an exception. Also, I had to manually create the database *and* the tables. This is ok in 3.2.2, the destination manager now accepts a message cache attribute. It makes more sense this way around. The old style is still supported, but it can lead to circular dependencies. In 3.2.1 it only accepted CREATE_TABLES=true, in 3.2.2 it ignores the case in the comparison. The default is true, so just removing that property will work. On the other hand, even if things work now, I get a strange Hypersonic exception when starting JBoss, right when jms/jboss-service.xml gets deployed - I've included the stack trace in the attachment. Should I worry about it? __ 17:52:18,059 INFO [MainDeployer] Starting deployment of package: file:/home/fane/builds/jboss-3.2.1/server/default/deploy/jms/jbossmq-service.xml 17:52:20,141 INFO [STDOUT] Server.run/init: java.sql.SQLException: Unexpected token: Unexpected token: in statement [] 17:52:20,301 ERROR [STDERR] java.sql.SQLException: Unexpected token: Unexpected token: in statement [] 17:52:21,029 ERROR [STDERR] at org.hsqldb.Trace.getError(Unknown Source) 17:52:21,029 ERROR [STDERR] at org.hsqldb.Log.runScript(Unknown Source) 17:52:21,029 ERROR [STDERR] at org.hsqldb.Log.open(Unknown Source) 17:52:21,030 ERROR [STDERR] at org.hsqldb.Database$Logger.openLog(Unknown Source) 17:52:21,030 ERROR [STDERR] at org.hsqldb.Database.open(Unknown Source) 17:52:21,030 ERROR [STDERR] at org.hsqldb.Database.init(Unknown Source) 17:52:21,030 ERROR [STDERR] at org.hsqldb.Server.openDB(Unknown Source) 17:52:21,030 ERROR [STDERR] at org.hsqldb.Server.run(Unknown Source) 17:52:21,031 ERROR [STDERR] at org.hsqldb.Server.main(Unknown Source) 17:52:21,031 ERROR [STDERR] at org.jboss.jdbc.HypersonicDatabase$2.run(HypersonicDatabase.java:250) Your hsqldb file is broken, if you are not using it any more you can delete it, it is in data/hsqldb Or just remove the hsqldb datasource deployment. Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
