Mule 3.6.1 MMC shows ESB with red circle - mule

I have a Mule 3.6.1 ESB server up and running and a MMC server to manage it. The problem I'm seeing is every time I need to restart the ESB server manually (to fix something) the MMC shows the server with an error (red circle) even when the ESB is back up and running normally (APIs are responding without issues).
Any idea how to fix this problem ?

This issue may occur for various reasons, the console polls the managed instances every certain period so you need to at least wait for that period of time to see this, also if you have something in between the console and the managed instance such as a proxy it might be caching the responses, finally I would check if it is a display issue, by trying to reload the page.

Related

WSO2 ESB "Sending a simple message" tutorial gives server port is already in use

I have been following the following tutorial
https://docs.wso2.com/display/ESB490/Sending+a+Simple+Message+Through+the+ESB
however, when I get to the section "To add WSO2 ESB as a server in Developer Studio" and specifically step 6 I get the error "Starting WSO2 Carbon 4.4 based server at localhost has encountered a problem. Server port is in use: 9443."
Since this is an introductory tutorial I am struggling to understand the problem. I could try different ports but worry I'm not understanding something although I have checked every step.
Have you run this tutorial successfully and how did you do it?
Check whether you already have a running ESB or any WSO2 Product. Normally this issue comes if you try to run multiple Products at the same time. kill all java/wso2 processors and retry.
Suggestion : use command line interface to start the server.
goto bin folder of wso2 esb and type the command wso2server.bat.
This happens when going through the initial steps of WS02, one would have started the EI or the ESB. Go back to command prompt and close the existing connection. Then come back to the tutorial and start the server. It will now start the server and the sample app will be available for testing

Mule ESB Instance Monitoring

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.

How to verify if Mule server is deployed or not?

How to verify if Mule server is deployed or not? My intention is to send a query(HTTP or something else) to Mule server and to see if it is up or down. This I want to do when no applications are deployed on the Mule server. This is to do validation post Mule server deployment. I am using community edition v3.3.0 and v3.4.0. I cannot use Mule EE version.
Thanks and Regards
Jai
That seems like a good idea.
The other option is to have you mule app sending a notification when started.
I know you said you can't use EE but the MMC module is probably what you need.
In any case they only problem with the previous approach is if you have a connectivity problem in the server you have your mule app running, but I reckon in that case you'll have several other problems.
HTH
Whenever hit the http we can see the response in console or in the logs.
First check whether your sever is running or not, give the proper url.

NServiceBus - Messages are going to Error queue directly without processing

We have an issue with a windows service which uses nServiceBus. At some random moment, the nServiceBus stops processing messages and direct them directly to Error queue, and I have to restart the service. After the restart, the messages arrived in the input message queue are handled, and everything gets back to normal. If we re-drop the messages which were went to error queue, it is processing it successfully without any issue.
We are using log4net logs to audit the message flow and storing in DB. The NServiceBus Handler stops to log in log4net. After we restart the windows service (NServiceBus) then it start to log again. We are NOT able to redproduce this issue in development environment. We are suspecting this could be a NService Bus Memory Leak issue. But we don't know how to confirm this issue and resolve the same.
We are planning to move this Windows Service (NServiceBus) to different server as a trial and error basis. Did anyone face this issue ever and resolved it? Please help us to resolve this issue as it is causing more troubles in Production environment.
NServiceBus Version that we are using : 2.0.0.1329
Message queue and windows service are in the same machine.
I believe you're running on a version of NServiceBus that is about 5 years old and is no longer supported. While I could give you the standard recommendation of upgrading to a more current release, it could very well be that some of the configuration APIs that you're using have been made obsolete so you may need to make some modifications there and/or in the app.configs.
I'm sorry to say that there probably isn't a better solution for you at this time.
In general, I'd suggest trying to track the NServiceBus releases somewhat more closely. If you're within 6-12 months of the current release, you should generally be in good shape.

Why are my WebLogic clustered MDB app deployments in warning state?

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.