I am running weblogic portal 10.3
We recently upgraded our oracle from 11.2 to 12.1.0.2.0
The 11g database schema was dumped when Weblogic was running and then imported to the 12c DB.
But now I see a strange problem:
On startup in my managedServer1.log.yyyy-MM-ddTHH-mm log file I see the following exception:
####<Sep 8, 2016 11:28:41 AM CEST> <Error> <DataSync> <devmaster.xxx.com> <managedServer1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0002F70BB8045A5B8E84> <e54db9af27ea4009:1806ee21:157091f8869:-7ffd-0000000000000002> <1473326921799> <BEA-400610> <Error performing initial refresh of persistent store. DataSync is probably in an incomplete or corrupted state.com.bea.p13n.management.data.repository.PersistenceException: Failed to refresh JDBC Persistence Manager.
at com.bea.p13n.management.data.repository.persistence.transactions.AbstractTx.sync(AbstractTx.java:67)
at com.bea.p13n.management.data.repository.persistence.JdbcDataSource.refresh(JdbcDataSource.java:215)
at com.bea.p13n.management.data.repository.persistence.JdbcPersistenceManager.refresh(JdbcPersistenceManager.java:113)
at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.<init>(AbstractDataRepository.java:164)
at com.bea.p13n.management.data.repository.MasterDataRepository.<init>(MasterDataRepository.java:49)
at com.bea.p13n.management.data.repository.DataRepositoryFactory.getMasterDataRepository(DataRepositoryFactory.java:441)
at com.bea.p13n.property.internal.PropertySetManagerImpl.ejbCreate(PropertySetManagerImpl.java:274)
at com.bea.p13n.property.internal.PropertySetManager_bjbwe8_Impl.ejbCreate(Unknown Source)
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 weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:232)
at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:132)
at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:148)
at weblogic.ejb.container.internal.BaseRemoteObject.preInvoke(BaseRemoteObject.java:229)
at weblogic.ejb.container.internal.StatelessRemoteObject.__WL_preInvoke(StatelessRemoteObject.java:41)
at weblogic.ejb.container.internal.SessionRemoteMethodInvoker.invoke(SessionRemoteMethodInvoker.java:24)
at com.bea.p13n.property.internal.PropertySetManager_bjbwe8_EOImpl.getPropertySets(Unknown Source)
at com.bea.wsrp.consumer.management.ProducerManagerImpl.internalGetCustomUserProperties(ProducerManagerImpl.java:867)
at com.bea.wsrp.consumer.management.ProducerManagerImpl.<init>(ProducerManagerImpl.java:116)
at com.bea.wsrp.consumer.management.producer.ProducerManager$Factory.<clinit>(ProducerManager.java:663)
at com.bea.wsrp.consumer.registry.DbProducerRegistryAdapter.sync(DbProducerRegistryAdapter.java:60)
at com.bea.wsrp.consumer.registry.ProducerRegistry$AddOrUpdateProducerAction.run(ProducerRegistry.java:725)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
at com.bea.wsrp.consumer.registry.ProducerRegistry.refreshProducers(ProducerRegistry.java:420)
at com.bea.wsrp.consumer.registry.ProducerRegistry.loadRegistry(ProducerRegistry.java:286)
at com.bea.wsrp.consumer.registry.ProducerRegistry.load(ProducerRegistry.java:196)
at com.bea.wsrp.consumer.registry.ProducerRegistry.getInstance(ProducerRegistry.java:160)
at com.bea.netuix.servlets.manager.PortalServlet.startProducerRegistryFilePoller(PortalServlet.java:599)
at com.bea.netuix.servlets.manager.PortalServlet.reinitInternal(PortalServlet.java:313)
at com.bea.netuix.servlets.manager.PortalServlet.initInternal(PortalServlet.java:268)
at com.bea.netuix.servlets.manager.PortalServlet.access$200(PortalServlet.java:125)
at com.bea.netuix.servlets.manager.PortalServlet$ServletLifecycleListenerImpl.init(PortalServlet.java:2190)
at com.bea.netuix.util.ServletLifecycleListener.initOrReinitInternal(ServletLifecycleListener.java:131)
at com.bea.netuix.util.ServletLifecycleService.addServletLifecycleListener(ServletLifecycleService.java:252)
at com.bea.netuix.util.ServletLifecycleService.addServletLifecycleListener(ServletLifecycleService.java:183)
at com.bea.netuix.servlets.manager.PortalServlet.init(PortalServlet.java:259)
at com.bea.netuix.servlets.manager.PortalServlet.init(PortalServlet.java:236)
at javax.servlet.GenericServlet.init(GenericServlet.java:242)
at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:283)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:64)
at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:539)
at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1984)
at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1958)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1877)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3174)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1527)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:489)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:427)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:201)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:249)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:427)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:28)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:672)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:59)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:187)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:379)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:52)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:31)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:170)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:124)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:181)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:97)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:263)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: com.bea.p13n.management.data.repository.PersistenceException: Cannot commit: java.sql.SQLException: Could not commit with auto-commit set on
at com.bea.p13n.management.data.repository.persistence.transactions.AbstractTx.doTransaction(AbstractTx.java:118)
at com.bea.p13n.management.data.repository.persistence.transactions.AbstractTx.sync(AbstractTx.java:62)
at com.bea.p13n.management.data.repository.persistence.JdbcDataSource.refresh(JdbcDataSource.java:215)
at com.bea.p13n.management.data.repository.persistence.JdbcPersistenceManager.refresh(JdbcPersistenceManager.java:113)
at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.<init>(AbstractDataRepository.java:164)
at com.bea.p13n.management.data.repository.MasterDataRepository.<init>(MasterDataRepository.java:49)
The result of this is that EJBs cause some NullPointerExceptions and my code fails. If I refresh the page enough times, the EJBs seem to be refreshed and start working fine.
But on restarts this problem shows up again.
I tried clearing out the WEBLOGICJMSSTATE table before start up, but there seems to be no effect.
Any suggestions?
Thanks.
Turned out to be an issue with the new driver. I guess the clue was in the text
java.sql.SQLException: Could not commit with auto-commit set on
I got rid of the error setting this JVM param:
-Doracle.jdbc.autoCommitSpecCompliant=false
Thanks to the answer here: java.sql.SQLException: Could not commit with auto-commit set on at oracle.jdbc.driver.PhysicalConnection.commit(PhysicalConnection.java:4443)
Related
I am running 2 instances of Jboss Datagrid server in RHEL in distributed mode. I am using leveldb cache store as my level 2 cache. Both of these instance should use the same leveldb cache store path and should write the key/value to this path.
/shared/usr/local/leveldb.
here is my configuration
(There is a softlink created inside the data directory so that the leveldb path is pointed to the same shared directory in both servers).
I am getting the following error on the second instance (first instance is comping up without any issues). I am using shared="true" in the configuration which should allow both datagrid servers to access the same cache store.
2016-12-05 13:15:19,077 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.datagrid-infinispan.clustered.mycache: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.clustered.mycache: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:864)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:238)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:877)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452)
at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.getCache(AbstractDelegatingEmbeddedCacheManager.java:133)
at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:130)
at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:127)
at org.infinispan.security.Security.doPrivileged(Security.java:76)
at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:63)
at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:135)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:86)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 21 more
Caused by: org.infinispan.commons.CacheConfigurationException: Unable to open database
at org.infinispan.persistence.leveldb.LevelDBStore.start(LevelDBStore.java:108)
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:141)
... 26 more
Caused by: org.fusesource.leveldbjni.internal.NativeDB$DBException: IO error: lock /shared/usr/local/leveldb/data/mycache/LOCK: Resource temporarily unavailable
at org.fusesource.leveldbjni.internal.NativeDB.checkStatus(NativeDB.java:200)
at org.fusesource.leveldbjni.internal.NativeDB.open(NativeDB.java:218)
at org.fusesource.leveldbjni.JniDBFactory.open(JniDBFactory.java:168)
at org.infinispan.persistence.leveldb.LevelDBStore.openDatabase(LevelDBStore.java:153)
at org.infinispan.persistence.leveldb.LevelDBStore.start(LevelDBStore.java:104)
... 27 more
The LevelDB cache store cannot be shared, because LevelDB itself is not meant to be shared. I've created an issue to ensure that such mistakes can be prevented during configuration validation: https://issues.jboss.org/browse/ISPN-7286
I am trying to run the OWBClient.sh with the command in UNIX and I am getting the following error:
" The JVM option is invalid: -XX: MaxPermSize=256M. Could not create the Java Virtual Machine."
OWB Version: 10.2.0.5
Oracle Database : 10g
UName: AIX
When exploring more on the above issue, I got an information that OWB 10.2 could not be run in AIX. It would be helpful if anyone can can shed some light on whether OWB 10.2.0.5 can be run on AIX?
Editing my post to share an update.I have tried to execute the owbclient.sh file by removing the -XX:MaxPermSize=256M part. I am now getting a different kind of error...
$ ./owbclient.sh
[Launcher]: Error! Cannot find and load the jar file '../../../jdk/jre/lib/ rt.jar'. OWB application may not be launched due to this error.
[Launcher]: Error! Cannot find and load the jar file '../../../jdk/jre/lib/ jce.jar'. OWB application may not be launched due to this error.
StaticLoader: Setting locale to en__
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:58)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at Launcher.main(Launcher.java:167)
Caused by: java.lang.InternalError: Can't connect to X11 window server using ':0 .0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:1 75)
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java:180)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvi ronment.java:91)
at sun.awt.motif.MToolkit.(MToolkit.java:124)
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java:180)
at java.awt.Toolkit$2.run(Toolkit.java:796)
at java.security.AccessController.doPrivileged1(Native Method)
at java.security.AccessController.doPrivileged(AccessController.java:287 )
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:787)
at java.awt.Component.getToolkitImpl(Component.java:873)
at java.awt.Component.getToolkit(Component.java:857)
at java.awt.Component.createImage(Component.java:2729)
at oracle.wh.ui.common.CommonUtils.getIcon(CommonUtils.java:622)
at oracle.wh.ui.framework.beans.splash.SplashBean.setImageLoc(SplashBean .java:111)
at oracle.wh.ui.framework.beans.splash.SplashBean.(SplashBean.java :42)
at oracle.wh.ui.framework.StaticLoader.main(StaticLoader.java:67)
... 6 more
java.lang.reflect.InvocationTargetException
$
I followed this https://github.com/imduffy15/GSoC-2014/ and installed apache cloudstack with basic networking in my local machine, and every thing worked smoothly.
I can add instances from the built in tiny linux template(cent-os 5.6 64bit) without having any issue.
I got a snapshot of the running instance volume and created a template from it. When I try to add an instance using that template I always get InsufficientServerCapacityException.
According to my dashboard there are enough capacity to add the instance.
Any ideas?
console:
WARN [o.a.c.alerts] (API-Job-Executor-5:ctx-4692c763 job-166 ctx-b141500e) alertType:: 8 // dataCenterId:: 1 // podId:: null // clusterId:: null // message:: Failed to deploy Vm with Id: 29, on Host with Id: null
INFO [o.a.c.a.c.a.v.DeployVMCmdByAdmin] (API-Job-Executor-5:ctx-4692c763 job-166 ctx-b141500e) com.cloud.exception.InsufficientServerCapacityException: Unable to create a deployment for VM[User|i-2-29-VM]Scope=interface com.cloud.dc.DataCenter; id=1
INFO [o.a.c.a.c.a.v.DeployVMCmdByAdmin] (API-Job-Executor-5:ctx-4692c763 job-166 ctx-b141500e) Unable to create a deployment for VM[User|i-2-29-VM]
com.cloud.exception.InsufficientServerCapacityException: Unable to create a deployment for VM[User|i-2-29-VM]Scope=interface com.cloud.dc.DataCenter; id=1
at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:214)
at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:200)
at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3515)
at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3166)
at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3154)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy224.startVirtualMachine(Unknown Source)
at org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin.execute(DeployVMCmdByAdmin.java:48)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
I replied to your private email. Will reply here for anybody googling the issue.
This is most likely due to the service offering you are using.
The default Cloudstack service offerings use shared storage. The setup for my GSoC project is all local storage.
You can create a new service offering via the UI and just specified local storage.
Alternatively, open up the SQL database, navigate over to the service_offering_view and modify the use_local_storage column to be 1.
EDIT:
Can you look at the template_view for the template you created based off a volume. Check that the column flag for HVM is set to 0.
So, basicly:
there is a standalone (no cluster) new installation of Glassfish 3.1.2 on RHEL 6.2 and Java 6 without any deployed applications (really new installation).
I started default domain domain1 on the server for the first time and stopped it without anything done between start/stop.
When i start the domain again, t get following error:
Waiting for domain1 to start ...Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
Launching GlassFish on Felix platform
04.06.2011 18:27:47 BundleProvisioner update
INFO: Updated bundle 1 from /home/glassfisfusr/glassfish3/glassfish/modules/endorsed/jaxb-api-osgi.jar
04.06.2011 18:27:47 BundleProvisioner update
INFO: Updated bundle 2 from /home/glassfisfusr/glassfish3/glassfish/modules/endorsed/javax.annotation.jar
04.06.2011 18:27:47 BundleProvisioner update
INFO: Updated bundle 3 from /home/glassfisfusr/glassfish3/glassfish/modules/endorsed/webservices-api-osgi.jar
04.06.2011 18:27:47 BundleProvisioner update
skipped
04.06.2011 18:27:49 BundleProvisioner update
INFO: Updated bundle 319 from /home/glassfisfusr/glassfish3/glassfish/modules/autostart/osgi-ee-resources.jar
04.06.2011 18:27:49 OSGiFrameworkLauncher launchOSGiFrameWork
INFO: Updating system bundle
Exception in thread "main" 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 com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.glassfish.embeddable.GlassFishException: java.lang.IllegalStateException: Bundle in unexpected state.
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:164)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
... 6 more
Caused by: java.lang.IllegalStateException: Bundle in unexpected state.
at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4856)
at org.apache.felix.framework.Felix.start(Felix.java:809)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:157)
... 9 more
Error stopping framework: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)
Take a look at this bugreport: http://java.net/jira/browse/WSIT-1642?page=com.atlassian.streams.streams-jira-plugin%3Aactivity-stream-issue-tab
The following does help:
rm -rf $GF_HOME/glassfish/domains/domain1/osgi-cache/
Occasionally we also get (ubuntu 12.04, glassfish 3.0.1, Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
[#|2012-06-13T19:17:02.763+0000|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=11;_ThreadName=Thread-1;|ERROR: Error locking file:/opt/glassfish/glassfish/modules/org.eclipse.persistence.jpa.modelgen.jar (java.lang.IllegalStateException: Bundle in unexpected state.)|#]
[#|2012-06-13T19:17:02.764+0000|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=11;_ThreadName=Thread-1;|java.lang.IllegalStateException: Bundle in unexpected state.
at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4474)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1049)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:662)
|#]
Haven't found any solution, except that sometime completely removing (mv /installationpath/glassfish /tmp/.) and re-installing glassfish works. You may also want to delete/move .updatetool from glassfish runtime user home dir.
Removing cache is not a good idea.
Problem you are having is coming from your system time.
If you are using Linux based OS than you must synchronize your system with an NTP server before starting glassfish.
run
service ntpd stop
ntpdate pool.ntp.org
service ntpd start
If that does not help, create file /var/lib/ntp/ntp.drift
and paste this in that file:
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
run
service ntpd restart
and you're done. You can start glassfish now..
run cmd with administrator
asadmin start-domain
We are experiencing problems when trying to publish or unpublish certain pages and structure groups following a migration to from SDL Tridion 5.2 to 2011 SP1.
The publishing transaction is failing at the Committing Deployment stage, and is returning the following error message:
Phase: Deployment Prepare Commit Phase failed, Unable to prepare
transaction: tcm:0-682623-66560, null, null
The cd_deployer.exe service is also running at almost 100% CPU Usage around the same time.
We also get the following information in the cd_deployer.log and cd_core.log files:
2012-05-02 07:32:09,346 ERROR DeployPipelineExecutor - Unable to start processing deployment package with transactionId: tcm:0-682520-66560
2012-05-02 07:36:36,071 ERROR DeployPipelineExecutor - Final attempt in Phase: Deployment Prepare Commit Phase failed for transaction: tcm:0-682526-66560
2012-05-02 07:36:36,071 ERROR DeployPipelineExecutor - Original stacktrace for transaction: tcm:0-682526-66560
com.tridion.deployer.ProcessingException: Unable to prepare transaction: tcm:0-682526-66560, null, null
at com.tridion.deployer.phases.PreCommitPhase.handleFailure(PreCommitPhase.java:120) ~[cd_deployer.jar:na]
at com.tridion.deployer.phases.PreCommitPhase.execute(PreCommitPhase.java:101) ~[cd_deployer.jar:na]
at com.tridion.deployer.phases.DeployPipelineExecutor.runMainExecutePhase(DeployPipelineExecutor.java:186) [cd_deployer.jar:na]
at com.tridion.deployer.phases.DeployPipelineExecutor.doExecute(DeployPipelineExecutor.java:97) [cd_deployer.jar:na]
at com.tridion.deployer.phases.DeployPipelineExecutor.execute(DeployPipelineExecutor.java:61) [cd_deployer.jar:na]
at com.tridion.deployer.TransactionManager.handleDeployPackage(TransactionManager.java:80) [cd_deployer.jar:na]
at com.tridion.deployer.queue.QueueLocationHandler$1.run(QueueLocationHandler.java:176) [cd_deployer.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_30]
at java.lang.Thread.run(Unknown Source) [na:1.6.0_30]
Removing the component presentation from the page and republishing works OK. Using different component templates doesn't work, so the issue appears to be with the component somewhere.
Pages, binaries and DCPs are all being published to the file system. I did wonder if the problem related to publishing large binaries, however removing them from the component didn't make any difference.
Does anyone have any ideas how to resolve this?
Kind regards
EDIT: I have now tracked this down to a number of components which I am unable to publish or unpublish. When attempting to publish or unpublish the component, the transaction remains at the "Committing Deployment" stage for around 5 minutes with the cd_deployer service maxing out the CPU before eventually failing with the same error message.
If I create an identical copy of the component via copy and paste, this works fine, and goes straight through publishing in a couple of seconds with no impact on the server's CPU. Very strange!
EDIT 2: This is an example of what we currently have in our cd_storage_conf.xml file for each publication:
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="21_content" defaultFilesystem="false">
<Root Path="D:/WebSites/live/Website/wwwroot/" />
</Storage>
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="21_data" defaultFilesystem="true" defaultStorage="true">
<Root Path="D:/WebSites/live/Website/Data" />
</Storage>
<Publication Id="21" defaultStorageId="21_data" cached="false">
<Item typeMapping="Page" cached="false" storageId="21_content"/>
<Item typeMapping="Binary" storageId="21_content" cached="false"/>
<Item typeMapping="ComponentPresentation" storageId="21_data"/>
</Publication>
There isn't a specific type mapping for metadata.
Have you tried un-publishing then republishing the offending pages? This often solves the problem for me. I have a theory that sometimes an old failed transaction may have locked certain rows in the Broker. Un-publishing the page seems to free them up. This won't really solve the cause of the problem, but if it works it should help isolate the cause.
Check your cd_storage_conf - are you storing all metadata into the same location? If not, modify so this is the case.
If you are still using a cd_broker_conf and allowing the system to transform to the cd_storage_conf, it would be better to create your own cd_storage_conf, since you are encountering difficulties.
I remember that in the deployer conf, there is a Phasing setting. For each deploy tag, a phase is defined, as to WHEN the deploy handler is fired: Pre, normal & post.
Not sure what the exact config is, but whe experienced the problem when we were setting up the archive manager.
Also, we had problems with deploying/transporting, when the temporary work directory was overflown with data. clearing the folder (default to: c:\temp or c:\work ) will speedup the process.
2 cents...