I have a couple of Mule applications running on mule container version 3.3.0. Recently I have observed that one of my mule application is getting redeployed again and again in a loop continuously.
The Mule app first get deployed then immediately within 2-3 seconds the mule app gets un-deployed and then gets deployed automatically. This is happening in loop and I don't see any specific errors in the log.
Can somebody please help me out with this problem and let me know the reason for the above behavior and how to fix it.
Thanks
Jai
There has to be an error, the problem is probably that you don't see it. Try locating the logfile named mule.log (or mule_ee.log) rather than mule-app-APPNAME.log. You might find the error there.
Otherwise, triple check that there are no weird permissions on the directory app (as the lock file should be created there).
Related
Enviornment :
DCOS : 1.7 running on vagrant
There are many reasons this could fail, but you did not provide enough information to narrow it down. However, the most common problem observed when getting started is missing the bit about having a private vs public agent available and the role being specified in the app json. I can't tell from the single screen shot what environment you are running or the json for the apps you were trying to run. If you are really stuck, try visiting https://dcos.io/docs/1.7/administration/installing/custom/troubleshooting/ and check out their slack channel for assistance. https://dcos-community.slack.com/
I got the same problem when installing DCOS form the Azure template, when I logged in, it appeared that I had 0 nodes connected in my cluster (which is obviously not good). I reinstalled it from another template and it fixed my problem. Hope it helps.
I created a mule application and able to run/deploy it on my machine successfully. On running api-console is appearing in Anypoint-studio like this.
Now when I deployed this application on mule ESB server and try to hit api-console for this application using the following URL "https://mulesoft:ESB****/api/console"
Mule is saying RAML loading for prolonged time like the one shown in below image.
I am not able to resolve the issue after working hours on it, If anyone can suggest possible reasons for the occurrence of this issue. It would be a great help to resolve the same.
Is there a straight forward approach for JBoss AS to print messages to the console in eclipse? I intend to use them only for debugging purposes and nothing more (I swear).
I'm new to JBoss and I don't know where to start and what to do to get my System.out.println()-messages appear in the console.
Unfortunately I have been struggling too long for today to achieve this rather natural requirement. I'm using JBoss AS 7.1.
edit:
Ok, looks like this time the problem is sitting in front of the screen. I couldn't find my logging even in the server.log. The reason is that the code which I was executing throwed an error which prevented the sysouts from being printed to the console. I'm sorry. Thank you for your help.
If you make a Sysout in your application, you can find it at the server.log, inside the folder $JBOSS_HOME/standalone/log
That, however, is not the best practice, since there's a lot of configuration and possibility at the log. You can check more information about that here
But, if you just say System.out.println('hello world') it will be out at server.log
All logging after the boot is made there so there you can check your System.out.println() stuff
With a default install a console handler and a file handler are configured. If you want to log to either you just need to use a logger. Printing to System.out or System.err it will work as well, but I would suggest using a logging facade like JBoss Logging, SLF4J or even just J.U.L.
If you're wanting to run JBoss AS inside eclipse the easiest way is to use JBoss Tools. You can start, stop and deploy your application from within eclipse locally for testing.
In my project I had 2 log4j.proprties files one is provided by jboss other is in my workspace. I removed one log4j.properties file now I am able to see sysout on the console.
Forgive me if this is a stupid question, I'm fairly new to writing services. I've written a service that runs a timer and the timer code runs some checks to ensure our systems are up and running. It's written in VB.Net, framework 1.1. I then install the service using "sc create". The service works beautifully on the XP Pro machine that I'm developing on. However, when I install the service on a Windows 2003 server 64 bit, the service fails with error 1053 immediately. I put some debugging in to write to a text file as the first line of code in the OnStart function but even that doesn't run, so there must be a problem in the program starting up. Finally in desperation I created a brand new Windows Service in a new VB project in Visual Studio 2003 and compiled an empty service that merely declares and sets the value of a string variable in the OnStart function as follows:
Dim strTmp As String
strTmp = "hello"
Even that failed on the W2K3 server, but works fine on the XP dev machine.
The server has .Net Framework 1.1 installed and working, we use it in our CMS (written in ASP.Net 1.1).
The service runs as the local system account. I tried enabling interaction with the desktop but that didn't help. I ran Process Monitor and there are no access denied events. I emptied the Application Event Log, still doesn't work. No other events to help me out in the logs. Definitely using the Release build of the application. Permissions on the exe file are full control for System and for Admins.
Any ideas anyone? It must be something simple, but I'm damned if I can figure it out!
Thanks in advance.
#DavidHi, many thanks for the suggestions. I don´t think the first point is my problem, partly because the MS article is about stopping or pausing the service, mine fails on starting; but also because the service does not timeout, there is no 30 second wait, it fails immediately. Secondly, when you say add an exception handler to the service startup, do you mean the OnStart sub? I tried adding a debug file write in there, but I'll try adding an event log instead. Regarding the systems checks, it can't be that because the brand new empty test service I created shows the same behaviour and that does not do anything at all. You last point could be the key. My dev environment IS 32bit. I'll do some research on the corflags thing, or perhaps I can build a 64bit dev environment. Many thanks again, you've given me some new things to think about at least!
Ok, have found a workaround. I was putting my exe file in System32. When I put it in a different folder, created by myself, the service ran, albeit briefly. I then had to move the ini file and the log files that it reads/writes to that folder too, rather than System32, and all seems to work nicely. God knows why it doesn't like running from System32 but at least it works now! Thanks for the help guys.
This looks very similar to this question which might help you out:
Starting a windows service fails with error 1053
A couple of other things to look out for:
Make sure you don't have either of the following statements in your deployed service:
System.Diagnostics.Debugger.Launch
System.Diagnostics.Debugger.Break
You may need to run the service with an account other than Local System (depending upon the permissions required by your service).
The 1053 error is a timeout related to the service control manager waiting for the service to respond to your start request. There is a knowledgebase article that refers to managed service stop request issues specifically relating to Framework 1.1-based services, so it is not precisely describing your problem, but it may have relevance in your situation. The link is provided for your reference.
http://support.microsoft.com/kb/839174
The other suggestion I would make to further diagnose the issue is to determine whether the Start is failing due to a "hidden" exception occurring in your service's startup code; the start call would not see the exception and could make you think it was merely timing out.
I would suggest you add an exception handler to your service startup that does nothing more than log a message to the event log with the particulars of the exception if one is caught. That would at least give you an idea that something is going wrong specifically within the service, and give you more information than you have right now.
One last thought: Does the service check the systems you describe over a network connection? If so, LocalSystem won't have sufficient privileges to perform network access.
Good luck!
EDIT One other possibility:
Is your development environment/execuable 32-bit? You mention your server is 64-bit, so you may need to use the "corflags" tool that forces 32bit operation on your executable
corflags /32bit+ YourServiceExectubable.exe
The source for this information was the following SO post:
32-bit Windows services in 64-bit environment
**Unfortunately, it appears corflags is applicable only for 2.0 assemblies, and was designed for specifically this type of problem. **
What exactly happens when we do IISreset? What resources get released? We have an ASP.Net website (.net 1.1) which use Crystal reports 11. Lately, running reports are throwing several crystal report specific exceptions and then the users can't run reports anymore. Resetting IIS lets the users log back in and run the reports until it fails the next time. Knowing exactly what resources are released when IIS is reset will help us dig deeper to find the root cause. Any help?
Pretty much everything. All thread pools, asp, asp.net, shared memory, etc... will all be purged. Doing in IISReset is basically the same as going to Services->WWW Service->Restart. Also, it will affect SMTP and FTP if you are running these services as well.
To narrow your problem down slightly ( and to reduce impact ), you should try putting your website in its own App Pool. Then when it next hangs, see if restarting the app pool fixes the problem. Then you are limiting things to just one running web application, not completely taking down iis. If the problem persists and still requires an IISReset, you at least have one more datapoint to work with.
EDIT: In response to your additional comment, I would suggest you do as much logging as possible and see if the problem becomes obvious. http://learn.iis.net/page.aspx/579/advanced-logging-for-iis-70---custom-logging/
Obviously, a quick run through Event Viewer is probably a good idea.