After starting one server in a cluster we are getting below error while other node is working fine
Runtime synchronization failed (No constructor has a #ConstructorProperties for this set of items: [action, createdTime, downloadLink, message, multiLanguageMessagesJSON])
Server MobileFirst 7.1
Please advice ?
Such an error may happen because the faulty server may be missing the correct level of an iFix, unlike the rest of the servers in the cluster, or an iFix that was "partially" installed, i.e. it is missing the correct JEE .jar or the admin .war files.
Related
I want to delpoy the Execution Server in follwing environment:
Wildfly17.0.0.Final
JVM memory, min:64m, max:1024m
Execution Server WAR package: kie-server-7.22.0.Final-ee7.war
A message shows in deployment page of Wildfly's HAL Management Console:
{"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"kie-server-7.22.0.Final-ee7.war\".PARSE" => "WFLYSRV0153: Failed to process phase PARSE of deployment \"kie-server-7.22.0.Final-ee7.war\"
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found"}}
can someone help? thanks in advance!
It seems that you started WildFly with default standalone profile. However Kie server requires standalone-full profile as it uses JMS queues.
Please try to start WildFly with standalone-full profile. For linux based system you can achieve that using command:
./standalone.sh -c standalone-full.xml
Question: I thought Weblogic and GlassFish / Payara are completely different servers and do not share any common code/component. How come I reached a Weblogic CVE when using Payara?
Configuration: Both our development and production systems are under Payara:
Payara 4.1.1.171.1 Full edition
Oracle Java 1.8.0_144
CentOS 7
Symptoms:
we have illegal connection to url /wls-wsat/CoordinatorPortType11 and wls-wsat/ParticipantPortType, under Anonymous authentication despite having Apache Shiro as security system.
we have an unknown Pyhton program running in our Production. Nothing found in Development so far
Payara Development has shutdown once and one deployment failed ending having Payara stopped (start-domain was required). Payara Production has shutdown once. All of it for unknown reason, especially there were at most one or two users doing nothing special at the shutdown moments
What I can (not) do:
After seeing this and reading this, I think the problems is solved for WebLogic systems but I don't know the mapping GlassFish version <-> Weblogic version, if it exists
Unless I missed a big stuff, I haven't found anything related CVE-2017-10271 and Payara.
We are planning to upgrade to Payara 4.1.2.174 shortly but I have no guarantee it will fix this issue.
I'm trying to check how Shiro can block such connection
I'm asking this question to make sure that there is (or not) no relationship between WebLogic and GlassFish/Payara before opening an issue on Payara GitHub. I unsuccessfully tried to run the python script, I don't know Python :(
I've installed RabbitMQ (latest version downloadable from RabbitMQ website) on my Windows 10 machine. It installed with ERlang 19.1.
I'm trying to install RabbitMQ Web UI Management Tools using the following command (using RabbitMQ Command Prompt):
rabbitmq-plugins enable rabbitmq_management
I'm getting the following error:
The directory name is invalid.
The filename, directory name, or volume label syntax is incorrect.
The filename, directory name, or volume label syntax is incorrect.
Plugin configuration unchanged.
Applying plugin configuration to rabbit#[0x7FF9A8527044]... failed.
* Could not contact node rabbit#[0x7FF9A8527044].
Changes will take effect at broker restart.
* Options: --online - fail if broker cannot be contacted.
--offline - do not try to contact broker.
I've looked up on SO and tried stopping and restarting, overriding erlang cookie, but nothing helps.
I think there's a problem with RabbitMQ itself. The service itself is marked as started, but if I try to telnet the default port (5672) then it fails (it's not a firewall issue - I've disabled it).
Also I don't see an log files created for RabbitMQ or any related Event Logs messages. So it's hard to diagnose exactly the problem.
I also tried uninstalling and re-install both erlang and RabbitMQ. Still didn't help.
How do I further diagnose the problem?
Found a solution to the problem (downgrading Erlang did not work in my case, but just in case I left it on Erlang 18 in case there were other issues with ver 19).
What puzzled my eye was this line: Applying plugin configuration to rabbit#[0x7FF9A8527044]... failed.. Seems like it's trying to connect to rabbit instance at a wrong machine name.
I then ran rabbitmqctl.bat status which failed but again showed that it's trying to connect to [0x7FF9A8527044] while the node name was rabbit#my-mchine-name. So I started reading the configuration section at RabbitMQ website and the solution was simple - setting the node name manually.
All I had to do is add an environment variable named RABBITMQ_NODENAME with the node name being rabbit#localhost. And that's it. Problem solved!
you may be running into issues with Erlang 19 incompatibility. there has been some history of Erlang 19 support problems with RMQ. Try installing Erlang 18 instead.
If that fails, I would recommend using Docker for Windows and installing / running RabbitMQ in that. I've moved all my services like RabbitMQ, MongoDB, etc. into Docker containers and it's made my life as a dev so much simpler.
In my case I had to trash the local account config located at : %APPDATA%\RabbitMQ\.
Deleting the entire folder and reinstalling the service did the trick.
Rabbitmq 3.6.14
Erlang 20.1 OTP
I followed the tutorial instructions :
Install MobileFirst Platform Server 7.1 on Bluemix (https://mobilefirstplatform.ibmcloud.com/labs/administrators/7.1/bluemix/)
I used Cloudant NoSQL DB as database.
It works well for several days.
But after a weekend without use, it doesn't work and i have this message on MobileFirst Operations console: Runtime synchronization failed.
console message
I tried to restart the container and the database application server (liberty) but i've always the same message.
I have to remove the container and repeat the whole procedure.
This is the third time it happens.
Try setting JNDI ibm.worklight.admin.farm.reinitialize value to true in server.xml. This will re-initalize the farm entries in other words it will clear the stale entries when the application crashes.
Reference : List of JNDI Properties for MFP Administration
seems like you are using the Cloudant shared plan. The shared plan response is not guaranteed like the dedicated Plan. To account for this vagarancies, there was a fix released to 7.1 that you should apply that adds the resiliency needed for the non response from the Cloudant shared plan. Pl apply the latest iFix and this should get solved.
I am trying to generate thread dump from weblogic console(Server-> -> Monitoring -> Threads -> Dump Thread Stacks.
I am getting below message: Server must be running before thread stacks can be displayed.
But, when I try to generate thread dump using kill -3 <PID>, it gets generated.
OS: Centos
Weblogic: WebLogic Server Version: 10.3.6.0
Can anyone please help me in understanding, why thread dump does not get generated from console and Why I am getting the message saying server must be running.
NOTE: Server is in running state.
As you are executing the Thread Dump command from Console, there might be an issue with AdminServer and managed server communication.
Console uses WLST to capture Thread Dumps and before generating thread dumps it will check Managed Server status. May be Admin Server unable to get current state of Managed Server hence you're seeing the error.
Recommended way to take Thread Dumps is OS command (kill -3 ) and from JDK tools, jstack for hostpot and jrcmd for JRockit. Thread Dumps taken from Console might not have lock related information and it might get truncated if thread dump is too long
I guess you was using JDK 7. It is a kind of bug in WLS 10.3.6.0 when using JDK 7. You can either downgrade the JDK to JDK 6 or patch the weblogic.