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.
Related
In MFP 8, How do i delete the deployed ADAPTERS from DB instead of MFP Console.
During development, we have deployed many adapters, Deleting one by one from MFP console is time consuming.
In MFP 8.0, an artifact deployment ( application registration or adapter) involves more than one table. As such, a deletion directly from the MFP administration database is error prone and can cause issues , if not done correctly.
To prevent such issues, you should either delete the adapter directly from console or via REST API. However, you can only do so, one at a time.
what is the best way to monitor the Mule ESB instances. Is there a way i can get alerted when my mule instance goes down for some reason. I have 4 instances of Mule running and how will I come to know if 1 of them got down due to some reason.
Thanks!
I assume you are running community edition? (Enterprise edition provides a Management Console which allows you to define alerts). If you are using CE, then you are able to enable JMX monitoring on the instances and then use one of many ways to verify based on JMX info, whether your server is running. One way is to write your own application that retrieves JMX data programmatically and act accordingly.
HTH
If you are using Mule EE, you can use MMC to monitor all your instances as Gabriel has already suggested. My suggestion would be to install MMC inside tomcat on a separate server. This is to ensure that even if your Mule Server crashes or goes down, your MMC is still running and can send you alerts about your Mule server downtime. You can refer below link for details on how to setup server down and up alerts.
https://developer.mulesoft.com/docs/display/current/Working+With+Alerts
Additionally I would recommend to use MMC with database persistence to ensure you have ability to recover MMC workspace even if your MMC server crashes. You can refer about MMC setup with DB persistence at below link.
https://developer.mulesoft.com/docs/display/current/Configuring+MMC+for+External+Databases+-+Quick+Reference
If you don't have Mule EE, you may want to explore other tools or customer alerting applications as suggested by Gabriel.
HTH
You can set up a JMX agent by adding the following lines into your "conf/wrapper.conf" file :
wrapper.java.additional.19=-Dcom.sun.management.jmxremote
wrapper.java.additional.20=-Dcom.sun.management.jmxremote.port=10055
wrapper.java.additional.21=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.22=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.23=-Djava.rmi.server.hostname=127.0.0.1
don't forget to change the values accordingly. Also you can implement SSL authentication with a few extra lines.
Now once your monitoring platform is set up you can always activate Java pollers and start the server.
Let's assume I have a cluster of 2 worklight servers sharing the same WL runtime.
On that runtime, I've installed a application with a adapter that is a create event source function.
Just like this IBM article.
https://www.ibm.com/developerworks/community/blogs/worklight/entry/configuring_a_polling_event_source_to_send_push_notifications?lang=en
My question is, what will happen on a cluster environment.
Will repeated work ensue?
By other words, would my two WL Servers will be pooling for events?
Or perhaps that functionality is writing a task on the WL DB that the WL Servers poll regularly to check for work if no instance is taking care of it, so that only a server at a time would be "the event source"?
I'm working with IBM Worklight 6.2 and Websphere Liberty Profile 8.5.5
Thanks in advance!
Here's my attempt to answer this after some consultation:
My question is, what will happen on a cluster environment. Will
repeated work ensue? By other words, would my two WL Servers will be
pooling for events?
While the Worklight Servers share the same runtime, they are still considered as 2 instances. This means that each of them will attempt to perform a polling action. This is considered OK.
However, it is important to note that the backend system that is being polled should likely be smart enough to handle such a situation where 2 polling attempts are done for the same message.
If the backend doesn't know how to handle polling properly, the same message can be pulled more than once. This is true even of you have a single eventsource running. So this is something to keep in mind.
I have been tasked with integrating ActiveMQ with Weblogic (v 10.3.6.0).
I have downloaded ActiveMQ v 5.10.0, installed it upon the server and browsed to localhost:8161/admin in order to confirm that ActiveMQ is running.
I'm not sure how to progress from here in order to complete my goal. This link:
http://activemq.apache.org/weblogic-integration.html
.. suggests that there are two approaches to deploying ActiveMQ on Weblogic: either deploying a broker as an application or using a J2EE Connector. I'm investigating the latter approach as I have now installed ActiveMQ on the server (which means that I already have a running broker, I assume) but can't find much useful information on the Net about how to do this.
This page:
http://activemq.apache.org/resource-adapter.html
... suggests that it can be done via a JCA Resource Adapter but again does not give any details on how to do it.
If anyone has any advice or guidance, I'd appreciate it.
Thanks in advance.
Did you try this: http://activemq.apache.org/how-to-deploy-activemq-ra-versionrar-to-weblogic.html?
You will have to grab the resource adapter from maven.
Not that your local installation will help you much expect for testing etc. You should deploy AMQ inside WebLogic if you want it to serve as the JMS layer of WebLogic - otherwise a totally standalone installation is fine. But then you're done, and I suspect you want the deployed version non the less.
I have a WebLogic cluster on which I've deployed numerous topics and applications that use them. My applications uniformly show themselves in a Warning status. Looking at Monitoring on the deployment, I see the MDB application connects to Server #1, but on server #2 it shows this:
MDB application appName is NOT connected to messaging system.
My JMS Server is targetted to a migratable target, which is in turn targetted to the #1 server and has a cluster identified. And messages sent to either server all flow as expected. I just don't know why these deployments show in a Warning state.
WebLogic 11g
This can be avoided by using the parameter below
<start-mdbs-with-application>false</start-mdbs-with-application>
In the weblogic-application.xml, Setting start-mdbs-with-application to false forces MDBs to defer starting until after the server instance opens its listen port, near the end of the server boot up process.
If you want to perform startup tasks after JMS and JDBC services are available, but before applications and modules have been activated, you can select the Run Before Application Deployments option in the Administration Console (or set the StartupClassMBean’s LoadBeforeAppActivation attribute to “true”).
If you want to perform startup tasks before JMS and JDBC services are available, you can select the Run Before Application Activations option in the Administration Console (or set the StartupClassMBean’s LoadBeforeAppDeployments attribute to “true”).
Refer :http://docs.oracle.com/cd/E13222_01/wls/docs81/ejb/message_beans.html
this is applicable for the versions till 12c and later
I don't like unanswered questions, so I'm going to answer this one.
The problem is resolved, though I was not involved in its resolution. At present the problem only exists for the length of time it takes the JMS subsystem to fully initialize. During that period (with many queues, it can take a while) the JNDI system throws errors and the apps are truly in warning state. Once the JMS is fully initialized, everything goes green.
My belief is that someone corrected something in the JMS Server / Cluster config. I'll never know what it was.