Nullpointer exception when starting the application server - intershop

After setting up my local development environment I got a nullpointer exception, immediately after starting up the Nodemanager:
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at java.util.Properties.setProperty(Properties.java:166)
at com.intershop.beehive.tcm.event.MulticastPropertyMgrImpl.getProperties(MulticastPropertyMgrImpl.java:66)
at com.intershop.beehive.tcm.event.EventMgrImpl.start(EventMgrImpl.java:100)
at com.intershop.beehive.nodemanager.NodeManager.bootstrap(NodeManager.java:202)
at com.intershop.beehive.nodemanager.NodeManager.main(NodeManager.java:102)
[NodeManager] [2017-10-03 13:23:34.530 +0200] ERROR [nodemanager]:
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at java.util.Properties.setProperty(Properties.java:166)
at com.intershop.beehive.tcm.event.MulticastPropertyMgrImpl.getProperties(MulticastPropertyMgrImpl.java:66)
at com.intershop.beehive.tcm.event.EventMgrImpl.start(EventMgrImpl.java:100)
at com.intershop.beehive.nodemanager.NodeManager.bootstrap(NodeManager.java:202)
at com.intershop.beehive.nodemanager.NodeManager.main(NodeManager.java:102)

I was able to solve this by:
making sure the server folder (and all its subdirectories) has read/write access for 'Everyone'
remove 'server\share\system\tcm\config\cluster.id' and 'server\share\system\config\cluster.id'
Now the application server starts up as normal

Related

Unable to start the App Server from the command line

I cloned Websphere application machine and changed the hostname by the wsadmin.sh script.
DMGR and Node started successfully but when I start the server I got this error:
ADMU0111E: Program exiting with error: java.io.FileNotFoundException: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/CELL01/nodes/AppNode/servers/server01/server.xml (No such file or directory).
Note: I can start the server from the console only
The problem recovered after synced the node with master configuration and granted read/write permission for directive /opt/IBM/Webspere and its relative sub directives, Thanks all for your contributions and support.

Jboss Datagrid server leveldb cache lock - Resource temporarily unavailable

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

WebSphere 8.5, Why AdminApp returns "exception information: websphere.management.application.client.AppDeploymentException"

I have a very simply Jython script over Unix. It was working perfectly during WebSphere 7 and now, after we upgraded to WAS 8.5 it isn't working anymore. Obviously, I changed the path to point to WAS8.5. I spent the whole day struglling to find the reason for this falling and I am completely stuck. The exception descrition doesn't help much.
From a JCL JOB I call the Jython script.
/WebSphere/was85/dtl85cel/ledm85nd/DeploymentManager/profiles/default/bin/wsadmin.sh -lang jython -f /WebSphereDevelopment/scripts/dtl/WAS85/Install.jy
The Jython script is really simple.
Basically, I call AdminApp.install("myEAR path", ...with the options below:
-nopreCompileJSPs -installed.ear.destination /WebSphereDevelopment/MYAPP/dtl/curr/deployment/ -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname DVL-MYAPP -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -processEmbeddedConfig -filepermission ..dll=755#. .so=755#..a=755#.*.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude -asyncRequestDispatchType DISABLED -nouseAutoLink -contextroot / -MapModulesToServers ÝÝ MyApp MyApp.war,WEB-INF/web.xml WebSphere:cell=dtl85cel,node=wleMyAppa,server=WLEMYAPP¨¨
)
The error log is:
WASX7017E: Exception received while running file "/WebSphereDevelopment/scripts dtl/MYAPP/MYAPP_DTL_DEPLOY.jy"; exception information: com.ibm.websphere.management.application.client.AppDeploymentException: com.ibm.websphere.management.appliccation.client.AppDeploymentException: ÝRoot exception is java.lang.RuntimeException: Deploying /WebSphere/was85/dtl85cel/ledm85nd/DeploymentManager/profiles/d java.lang.RuntimeException: java.lang.RuntimeException: Deploying /WebSphere/wa s85/dtl85cel/ledm85nd/DeploymentManager/profiles/default/temp/app69105293327198772690.ear failed.
Turn on tracing under wsadmin.properties:
com.ibm.ws.scripting.traceString

Cloudify:: uninstallation-application fails

To uninstall an application I called uninstall-application app-name from the cloudify prompt in a local cloud environment. However the uninstall is unsuccessful. The log file shows following exception.
2013-10-14 13:06:50,537 rest [1] INFO [org.cloudifysource.rest.controllers.ServiceController] - Removing all application scope attributes for application
2013-10-14 13:06:50,542 rest [1] WARNING [org.openspaces.admin.internal.admin.DefaultAdmin] - Failed to execute: org.openspaces.admin.internal.gsm.DefaultGridServiceManager$3#70b1ec8b - org.openspaces.admin.AdminException: Failed to undeploy processing unit [app-name]; Caused by: org.openspaces.admin.AdminException: Failed to undeploy processing unit [app-name]
at org.openspaces.admin.internal.gsm.DefaultGridServiceManager.undeployProcessingUnit(DefaultGridServiceManager.java:279)
at org.openspaces.admin.internal.gsm.DefaultGridServiceManager$3.run(DefaultGridServiceManager.java:799)
at org.openspaces.admin.internal.admin.DefaultAdmin$LoggerRunnable.run(DefaultAdmin.java:2077)
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:724)
Caused by: org.jini.rio.core.OperationalStringException: GSM not found
at org.jini.rio.monitor.ProvisionMonitorImpl.undeploy(ProvisionMonitorImpl.java:601)
at org.jini.rio.monitor.ProvisionMonitorAdminImpl.undeploy(ProvisionMonitorAdminImpl.java:126)
at org.jini.rio.monitor.DeployAdminGigaspacesMethodinternalInvoke7.internalInvoke(Unknown Source)
at com.gigaspaces.internal.reflection.fast.AbstractMethod.invoke(AbstractMethod.java:41)
at com.gigaspaces.lrmi.LRMIRuntime.invoked(LRMIRuntime.java:450)
at com.gigaspaces.lrmi.nio.Pivot.consumeAndHandleRequest(Pivot.java:557)
at com.gigaspaces.lrmi.nio.Pivot.handleRequest(Pivot.java:658)
at com.gigaspaces.lrmi.nio.Pivot$ChannelEntryTask.run(Pivot.java:196)
... 3 more
2013-10-14 13:06:51,544 rest [1] INFO [org.cloudifysource.rest.util.RestPollingRunnable] - undeployAndWait for processing unit has not finished yet
#
Eventually the operation times out. Post that I can not even teardown the local cloud. The only way to come out of this is the reboot the system. Appreciate some help on this one.
The following error:
Caused by: org.jini.rio.core.OperationalStringException: GSM not found at org.jini.rio.monitor.ProvisionMonitorImpl.undeploy
indicates that one of the Cloudify management components was missing. It may have crashed earlier, or perhaps the local machine was running at 100% CPU, causing local components to not respond to each other.
In an actual cloud deployment, this would cause the Cloudify agent to restart the failed component, but in the local-cloud environment the agent and the other management components run in the same process to conserve memory and speed up start-up time.

Large files with msdeploy

We are trying to use Web Deploy to improve our deployment.
Everything works internally but once we try to deploy to our online environment than msdeploy hangs on files lager than 1 MB.
If we remove those files, the sync works with msdeploy.
The client tries a few times to upload the file and then gives the following error:
Warning: Retrying the sync because a socket error (10054) occurred.
Retrying operation 'Serialization' on object MSDeploy.contentPath (sourcePath).
Attempt 4 of 25.
Info: Using ID '789c2466-2bae-4b56-b67d-1a1743cdb0f6' for connections to the remote server.
On the server we see the following error:
Content-Type: application/msdeploy
Version: 8.0.0.0
MSDeploy.VersionMin: 7.1.600.0
MSDeploy.VersionMax: 7.1.1070.1
MSDeploy.Method: Sync
MSDeploy.RequestId: 789c2466-2bae-4b56-b67d-1a1743cdb0f6
MSDeploy.RequestCulture: en-US
MSDeploy.RequestUICulture: en-US
Skip: objectName="^configProtectedData$"objectName="filePath",absolutePath=".*web.config$"objectName="filePath"
Provider: contentPath, Path: demo.com
Tracing deployment agent exception. Request ID '789c2466-2bae-4b56-b67d-1a1743cdb0f6'. Request Timestamp: '5/07/2011 11:29:56'. Error Details:
System.Net.HttpListenerException: An operation was attempted on a nonexistent network connection
at System.Net.HttpResponseStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at System.IO.BufferedStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at System.IO.StreamWriter.Dispose(Boolean disposing)
at System.IO.StreamWriter.Close()
at System.Xml.XmlTextWriter.Close()
at Microsoft.Web.Deployment.TraceEventSerializer.Dispose()
at Microsoft.Web.Deployment.DeploymentAgent.HandleSync(DeploymentAgentWorkerRequest workerRequest)
at Microsoft.Web.Deployment.DeploymentAgent.HandleRequestWorker(DeploymentAgentAsyncData asyncData)
at Microsoft.Web.Deployment.DeploymentAgent.HandleRequest(DeploymentAgentAsyncData asyncData)
Anyone any suggestions to fix the problem?
I have not had this issue so cannot give you a specific fix but the microsoft documentation says
Why does remote deployment fail for large files, although local deployment succeeds?
Typically when you deploy to production servers you are deploying across a firewall.
If you get end-of-stream errors on large files, check the settings on the firewall.
Unfortuately it doesnt give specifics regarding the firewall setting to check

Resources