I have multiple instances of MFP running, but my problem is that all the instances are writing logs to a single log file. How can I write logs to diff location for diff instances?
Assuming that by "multiple instances of MFP" you are referring to multiple MFP runtimes deployed on the same JVM,it is normal to see all logging appearing in the same log - SystemOut.log for WAS , messages.log for WebSphere Liberty etc.
This is because MFP is a layer that is deployed on top of the Application server and all logging from MFP is directed to the standard logging of the JVM. As such, if you deploy multiple runtime wars on the same JVM, it is normal to expect all logging from all the runtimes appear in the same log. This is not different from different EAR/WARs deployed on the same Application server, logging into the same log file.
If you wish to have different logs for different runtimes, deploy them in different JVM instances.
Related
I'm looking for the advice of how to manually (i.e. without using Runtime Manager - RM) deploy a mule application package on the on-premises Mule cluster. The official documentation suggests using the RM for the purpose either via the gui or cli or api. However, the RM is not available on our environment.
I can manually deploy the package on a single node by copying it to the /apps folder. But this way the application is only deployed on a single node, not on the cluster.
I've tried using the AMC agent rest API for the purpose with the same result - it only deploys on a single node.
So, what's the correct way of manually deploying a mule application on the Mule servers cluster without using Anypoint RM?
We are on Mule 4.4 EE.
Copy the application jar file into the apps directory of every node. Mule clusters do not transfer applications between nodes.
Alternatively ou can use the Runtime Manager Agent instead however it also works in a per node basis. You need to send the same request to each node to deploy.
Each connector may or may not be cluster aware. Read each connector documentation to understand how they behave. In particular the documentation of the VM connector states:
When running in cluster mode, persistent queues are instead backed by the memory grid. This means that when a Mule flow uses VM Connector to publish content to a queue, Mule runtime engine (Mule) decides whether to process that message in the same origin node or to send it out to the cluster to be picked up and processed by another node.
You can register the multiple nodes through AMC agent on the cloudhub control plane and create a server group and deploy code through control plain runtime manager it does the job of deployment to same app in n nodes
I have Gridgain three node cluster and also running Gridgain web console agent and web console on all three nodes. It is all hosted on Windows Server.
I would like to load balance My web console. The problem is I don't know how to share user registration database which it stores in a work directory. Can I use external database to store all that information so that my cluster uses the same database?
There is a problem with Web Console Agent as well. How do I share tokens stored in default.properties?
There is no definitive guide on how to create a cluster for web console for high availability.
Can someone please guide me on how can I form a cluster for a Web console sharing its user store and tokens?
Thanks
If you are looking for multi-cluster support, take a look at documentation:
https://www.gridgain.com/docs/web-console/latest/multi-cluster-support
If you are looking for agent fault-tolerance: just start several agents. Fisrt agent will process all messages, other will be in the hot-stand-by mode.
If you are looking for connection fault-tolerance between agent and cluster (if cluster node failed that is a connection point for agent, Web Console will loose connection to cluster), just specify several nodes addresses as comma-separated list for "node-uri" parameter (in default.properties or as command-line argument).
For example:
node-uri=http://192.168.0.1:8080,http://192.168.0.2:8080;http://192.168.0.3:8080
Hope this helps.
How mule decides that an event should be logged in app logs or runtime log ?
In runtime log all the logs are there even which are in app logs.
All that goes to standard output will be printed in the Mule Runtime logs (ie mule_ee.log). If the applications are configured to use stdout or console appender, then you'll get them in mule_ee.log. This is a bad practice. Applications should use their own log files. The default log4j configuration for applications created in Studio is a log per app.
I noticed that both options are available while running Jboss, and they both recompile the project (I noticed 'make' running with both). I did see this question, the accepted answer made sense, but I wasn't sure what hot-swapping means. What is a possible example of a change which could be registered without needing to restart the server?
Your question needs more details to answer completely, but here are some basic concepts:
Hot-swapping is simply replacing the files of your project into the deployment folder of the application server (unpackaged, i.e. not the .war/.ear but all separate files). It is usually faster because the change are immediately visible in the web-application. But it is not always possible/supported by application servers, and often if you hot-swap .jar files the application server doesn't pick it up or end up confused.
Restarting JBoss will stop all existing services ( EJBs, Pooling, Queues, Messaging...) and restart them. It is almost the cleanest way to run your application (the cleanest would be un-deploy, restart and deploy)
Redeploy means your application and its services are first removed from JBoss, but other services setup at server level (Messaging, Pools, JMX,... depends on your actual settings) are still deployed. Then the application is deployed (copied from your dev folder or .WAR/.EAR to JBoss webapp)
Typically, you would hot-swap (eventually manually) .(x)html/.jsp/.jsf/images/.js/.css safely as JBoss doesn't need to process them.
Changing code in java classes deployed as .class in a WEB-INF/classes can often be hot-swapped.
Changing code in java files deployed as .jar will almost always need at least redeployment. Some OSGi enabled application server properly configured are more flexible in hot-swapping a complete application (I know Glassfish does but I don't know what specific setting is needed)
Finally, in development, sometimes the multiple redeployments lead to memory leak or unstable application server (often you'll get a OutOfMemory exception in the logs) then you need to cleanup (undeploy, stop, start then deploy)
When running jboss 7.1 as a windows service (or not), it occasionally takes more than one try to successfully deploy a war file. This is not a problem when starting jboss manually since restarts are easy. However, when jboss runs as a windows service and it is restarted automatically (due to a windows patch), jboss itself may launch, but the war may not.
Is there any way to cause jboss to retry deploying the war after it fails the first time - for example, by changing a setting in standalone.xml?
There are to ways to fix your problem.
1) go to standalone.xml (or whatever configuration you are running), find deployment-scanner and add/modify attribute deployment-timeout in seconds
2) Deploy your application as managed deployment, you can do that if you deploy trough admin console or via cli with deploy command. This way deployment will then be "managed" and will always be deployed and wont be using deployment scanner and its timeouts.
I recommend you to use deploy as managed deployment as deployment scanner is not really recommend to be used in production environments as it adds additional IO load on filesystem.
It is great for development / testing scenarios but should be avoided in production if possible.