Whenever I try to run the hazelcast management cluster I get the following error
org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [collector] in context with path [/mancenter-3.4.2] threw exception
com.hazelcast.com.eclipsesource.json.ParseException: Expected value at 1:0
I am running hazelcast management center on tomcat 8.0. I am able to login without any issues but when I try to add any value to "Update Cluster URL" I get the above error.
I just downloaded 3.4.2 from hazelcast website.
Then i copied mancenter.war to tomcat8/webapps directory.
In hazelcast-3.4.2 folder, there is demo folder and i executed console.sh.
When i put entries to map, i saw these entries also in mancenter.
I didn't encounter any problem.
My tomcat version 8.0.23
When you try tomcat7, do you see errors?
This might be due to version mismatch between your Hazelcast cluster and management center.
What's your hazelcast version?
Related
I have integration test in maven verify, that starts Apache Cassandra 3.11.13. I'm using cassandra-maven-plugin 3.7. I tried moving the project to Java 11. After adding Java 11 vm options to cassandra-maven-plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cassandra-maven-plugin</artifactId>
<configuration>
<addJdk11Options>${runningJava11}</addJdk11Options>
.....
I've got Cassandra to start on Linux, but on Windows was crashing, unfortunately without logs.
I was able to craft the same JVM parameters used by the cassandra-maven-plugin, but added the slf4j-jdk14-1.7.32.jar to the class path. The JVM parameters can be printed when starting mvn -X, however the class path and main class can be found in git\software-app\target\cassandra\bin\cassandra.jar which is packed by the cassandra-maven-plugin. In the logs I found this error:
enter code here Aug 20, 2022 9:32:12 PM org.apache.cassandra.service.DefaultFSErrorHandler handleStartupFSError
SEVERE: Exiting forcefully due to file system exception on startup, disk failure policy "stop"
Aug 20, 2022 9:32:12 PM org.apache.cassandra.service.DefaultFSErrorHandler handleStartupFSError
SEVERE: Exiting forcefully due to file system exception on startup, disk failure policy "stop"
FSWriteError in C:\Users\pesho\git\software-app\target\cassandra\data\system\local-7ad54392bcdd35a684174e047860b377\me-8-big-Data.db
at org.apache.cassandra.db.lifecycle.LogTransaction.delete(LogTransaction.java:261)
at org.apache.cassandra.db.lifecycle.LogTransaction$SSTableTidier.run(LogTransaction.java:386)
at org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy.tidy(SSTableReader.java:2333)
at org.apache.cassandra.utils.concurrent.Ref$GlobalState.release(Ref.java:326)
at org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:225)
at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:119)
at org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier$1.run(SSTableReader.java:2238)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.nio.file.AccessDeniedException: C:\Users\pesho\git\software-app\target\cassandra\data\system\local-7ad54392bcdd35a684174e047860b377\me-8-big-Data.db
at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:274)
at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
at java.base/java.nio.file.Files.delete(Files.java:1142)
at org.apache.cassandra.db.lifecycle.LogTransaction.delete(LogTransaction.java:243)
... 13 more
It seems Cassandra is trying to delete a file, that is still open for reading. I was able to start Cassandra after modifying target/cassandra/conf/cassandra.yaml by setting:
disk_failure_policy: ignore
Since this a this a test only instance, I decided, I'm fine with this option.
Unfortunately this yaml file is generated by cassandra-maven-plugin. After some digging in the code of the plugin, I found the yaml parameter, which merges configs from pom.xml and default config file:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cassandra-maven-plugin</artifactId>
<configuration>
<!-- required to start on Windows -->
<yaml>disk_failure_policy: ignore</yaml>
<addJdk11Options>${runningJava11}</addJdk11Options>
.....
The Java file I/O library that Cassandra uses has always been problematic on Windows particularly with NTFS. It has been a constant source of issues for users that we decided it wasn't good for the project to continue support (see the discussion in this thread).
We eventually dropped Windows support completely in Cassandra 4.0 (CASSANDRA-16171).
Also, Cassandra 3.1x (and earlier versions) only work with Java 8 (see Cassandra installation prerequisites). Cassandra 4.0.2 added full support (previously experimental) for Java 11 only recently (CASSANDRA-16894). This means that C* 4.x will work with either Java 8 or Java 11.
The recommended workarounds for Windows users are:
Deploy Cassandra in Docker
Deploy Cassandra in a VM using software like VirtualBox
Deploy Cassandra in a Kubernetes cluster with K8ssandra.io
Otherwise if you just want to learn how to build apps on Cassandra, Astra DB has a free tier where you can launch a cluster in just 5 clicks. Cheers!
I am facing below issue while connecting to DB server(Suse linux machine B) from app Server (Suse linux machine A) which is contains WEbSphere Application Server, configured with DB2. please find below details.
ASX7015E: Exception running command: "AdminControl.testConnection('DB_NAME(cells/cell_name/nodes/node_name/servers/server1|resources.xml#dataSource_ID)')"; exception information:
com.ibm.websphere.management.exception.AdminException
javax.management.MBeanException
java.sql.SQLNonTransientException: java.sql.SQLNonTransientException: null DSRA0010E: SQL State = 08001, Error Code = -1,639.
not able to find root-cause of this error
not able to find, from which server this error came.
Note : This issue came after doing some path update on production issues. WebSphere version is 9.0, using websphere internal java and openJPA 2.0 and DB2 version is 11.1.0.0.
The sqlode -1639 is caused by incorrect permissions on files on the Db2-server.
See this technote
The advice given there, in case of broken links, is:
Cause
This is caused by incorrect permissions and ownership of the following security files in ~/sqllib/security directory
db2chpw
db2ckpw
These files should have root as owner and must have permission -r-s--x--x
Resolving The Problem
Change the owner of the files to root
Change the permission of the files to -r-s--x--x
Update the instance using db2iupdt
Apart from the above, it is always unwise to use any "fixpack 0" of any Db2 product to production environments on linux/unix/windows. There are always too many silly bugs that have long since been fixed by subseqent cumulative fixpacks. Your question mentions v11.1.0.0 (this is fixpack 0 of Version 11.1 ). Best advice is to deploy the current most recent fixpack to the Db2-server, so get your DBA to do this first on your development/test environments before deploying to production.
Additionally consider ensuring to maintain the Db2 jdbc driver version on your WAS server, instead of continuing to use the (usually old version) that comes with WAS. Best practice is to keep the version of the jdbc driver the same between the WAS and the Db2-server, so keep those versions maintained.
I'm following Liferay getting-started example to develop my first we app with Liferay IDE in which it is mentioned:
Even though all you’ve done is generate it, the guestbook-web project is ready to be built and deployed to Liferay DXP. Make sure that your server is running, and if it isn’t, select it in Developer Studio’s Servers pane and click the start button. After it starts, drag and drop the guestbook-web project from the Project Explorer to the server.
I started the server, however, I don't know how to deploy guestbook-web module to server. Drag and drop is not working for me:
When Opening the web page, this is shown which doesn't contain anything related to guestbook-web module:
Update
When I drag and drop my module on server, for some reason it is not allowed:
Update
Also, I'm receiving such errors on console:
22-Apr-2020 16:02:54.419 SEVERE [http-nio-8080-exec-6] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [Module Framework Servlet] in context with path [] threw exception [PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required] with root cause
org.apache.jasper.JasperException: PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
I have set both JDK and JRE path for IDE, not sure why it says A full JDK (not just JRE) is required.
Update
To fix A full JDK (not just JRE) is required error, inspired by this answer, I ran the IDE with this command:
C:\Program Files (x86)\LiferayWorkspacewithDevStudioCommunityEdition\liferay-developer-studio>DeveloperStudio.exe -vm "C:\Program Files\Java\jdk1.8.0_251\bin\javaw.exe"
The error is resolved and default widgets are fine now:
In the IDE: You'll drag the "guestbook-web" with the mouse and drop it right on the highlighted "Liferay 7.x at localhost" Server (Note: on, not below).
Outside of the IDE: Your project generates a jar, and you can copy that to Liferay's deploy directory.
Once the module is deployed, it won't magically show up on the page: Log in as Administrator, choose the "Add" button (a plus sign) and add a "widget" to the page: In the list of Widgets you'll find your new portlet/widget.
The screenshot of your installation looks weird though, as if something didn't go wrong and you'll likely need to look for signs of problems in the log file to see why Liferay ends up in the state that it's in, with a couple of default widgets being unavailable - however, that's unrelated to the question how to deploy new code to the runtime.
Edit: You've mentioned the required JDK from the log. That's good to be fixed.
With regards to the not-working drag&drop: It looks like you're using Liferay Workspace. From the icons in Project Explorer, it looks like your module isn't recognized as such: Try to "Gradle/Refresh Gradle Project" (right-click on "modules") to see if it needs some updates that are missing (and observe its log output). Icons on my IDE look like this:
Once you get those modules recognized, you should be able to drag&drop them to the server.
I realized to avoid A full JDK (not just JRE) is required error, it is needed to setup server correctly while creating it with GUI:
I'm running into a strange behavior with my liferay 6.2 (build 6210). I was trying to install the latest fixpack portal-84 and cannot start my server since. Since I reverted all fixpacks etc. and still the startup doesn't work I doubt the update is the reason. I get the following message Permission conversion to algorithm 6 has not been completed. Up until this point the startup looks normal. Strange thing is my database schema was never used for anything else than liferay 6.2.
10:42:13,566 ERROR [localhost-startStop-1][MainServlet:212] java.lang.IllegalStateException: Permission conversion to algorithm 6 has not been completed. Please complete the conversion prior to starting the portal. The conversion process is available in portal versions starting with 5203 and prior to 6200.
java.lang.IllegalStateException: Permission conversion to algorithm 6 has not been completed. Please complete the conversion prior to starting the portal. The conversion process is available in portal versions starting with 5203 and prior to 6200.
at com.liferay.portal.tools.DBUpgrader._checkPermissionAlgorithm(DBUpgrader.java:297)
at com.liferay.portal.tools.DBUpgrader.upgrade(DBUpgrader.java:135)
at com.liferay.portal.events.StartupAction.doRun(StartupAction.java:181)
at com.liferay.portal.ee.license.StartupAction.doRun(Unknown Source)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:74)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1245)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:209)
at javax.servlet.GenericServlet.init(GenericServlet.java:160)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1280)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1193)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5176)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5460)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635)
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)
Stopping the server due to unexpected startup errors
Is assume that something is wrong within my database (although I have no idea how that happened). When I start liferay with the embedded memory DB the startup works. There are only some other messages in the log because there are lucene files in filesystem without entries in memory db. select * from RELEASE_; states the correct version portal 6210 and my configured database connection is correct as well (tried with jndi resource in tomcat and with conenction information in portal-ext.properties). But maybe there is some other location where a version is saved and is vital to portal startup.
Did anyone ever had this behavior or is this a completely special case that is (more or less) exclusive to me?
Thanks ans regards. Sebastian
The upgrade script checks if the ResourceCode table is empty. It was used prior to Liferay 6, Liferay 6 upgrade scripts usually remove all data from it or the whole table whatsoever.
To overcome this issue I did all the steps according to this tutorial from Liferay. The only difference to your situation is that I'm using Liferay CE.
I am trying to use "Take Photo" feature from iPad but am getting the below error on save. It takes photo properly and able to see the details of it in Anywhere while clicking submit,Issue begins.
I have made the configuration changes already in app-features.properties, build.properties also.
Error Log:
[ERROR ] FWLSE0048E: Unhandled exception caught: SRVE0190E: File not found: /anywhereAttachment
java.io.FileNotFoundException: SRVE0190E: File not found: /anywhereAttachment
at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:528)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:127)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:88)
at com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:215)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:220)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:85)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:968)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1056)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:4553)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.handleRequest(DynamicVirtualHost.java:301)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:954)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:266)
at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:776)
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)
[project MaximoAnywhere]
SRVE0190E: File not found: /anywhereAttachment
This error means that the Anywhere Attachment servlet (for some reason) did not deploy successfully when you deployed the MaximoAnywhere.ear into the MobileFirst Server.
Can you compare the web.xml from the MaximoAnywhere.war in your MaximoAnywhere/bin directory, to the web.xml in your running MobileFirst Server? You should find some missing sections in the running MobileFirst server version.
Usually if they don't match, this is due to a MobileFirst behavior (bug?/feature?), where it strip/rewrite the web.xml if the MaximoAnywhere.war was built with a different version of the MobileFirst build libraries than the MobileFirst server. We ship and document an exact version of MobileFirst server iFix to match our packaged MobileFirst build libraries to try and prevent this problem, but if your version of MobileFirst server is out of sync, it can still happen.
You can just cut and paste the missing info from the web.xml into your deployed MaximoAnywhere.war web.xml.
you are missing anywhere attachmentServlet deployment ,
Look for War in MaximoAnywhere.war in /bin directory , if you are using , websphere then you need to deploy this war part of websphere jvm. look for your build.properties and check are you using local server or remote server and deploy correctly.