I am new to Karaf..
My apache karaf container runs around 20 OSGi bundles. Things work properly most of the time, but at times when the services are not accessible, i open the karaf console, I see that some of the bundles are in "Resolved" state, which originally was in "Active". What could probably cause a service in "Active" state to come down to "Resolved" state?
Thanks in advance
Related
I am evaluating a self-hosted artifactory installation on a trial license. I followed the official installation instructions for the docker container and the linux archive file. Neither of these installation options are working. The artifactory service fails to start.
I have opened an issue to track the problem: https://www.jfrog.com/jira/browse/RTFACT-27182
TL;DR; A component fails, a nasty stack trace appears in the logs, and eventually the services stop.
It would seem that there is a bug in artifactory. I have traced this back to multiple versions and this issue spans multiple years.
The problem appears to be that artifactory cannot get past the bootstrapping/initialization phase when started with artifactoryctl. At a certain point (around 2-5 minutes in) all the services stop and a pid file is left over, which is bad.
The workaround I have found is that the service can pass this initialization phase only after multiple start/stops (3 to be exact). In other words, we call artifactoryctl start, wait for all failures, then artifactoryctl stop and repeat two more times. On the fourth and final start, we will see the service come online (in about 150 - 190s). From then on, the service will start correctly with one call to artifactoryctl start.
I have not yet looked at the systemd unit file. My guess would be that it has/or could be made to have a number of retries to work around this issue and perhapse this issue does not exist when using the service wrapper.
I have also not yet looked again at the docker container which appears to be failing for the same reason. A workaround off the top of my head would be to modify the entrypoint script. If you were to dockerk exec into the container and try the workaround above it would likely terminate the root process and kill the container.
Tomcat 7 Throws an error saying the application requires more time to start but even if i increase the timeout to 600 sec the same error comes up , how can i run the application .
I am loading all the jars from https://repo.spring.io/release/org/springframework/spring/
I am using jdk 1.6
Version 4.2.5 But still error .
Please help how can i run my application.
Error image
Solution : remove all project from Tomcat server, then restart tomcat again.
Method :
Window tab -> show view -> select server --> then right click server -> add and remove --> remove all configured --> finish --> restart server, may it help you.
Tomcat 7 normally starts within a few seconds. It sounds like you have one of these problems:
Something is going drastically wrong - check all logs in the /logs directory there may be clues in there.
Something in the static initialisation code of one of your classes is taking forever. Put breakpoints in any static initialization code and see if they are reached, and that control is returned to Tomcat in a timely fashion.
Something in the static initialisation code of another deployed application is taking forever. Undeploy all other apps (if there are any) and try again.
Also, try undeploying your application. Does Tomcat start normally now? This will sort out whether the problem is the Tomcat installation or your application.
My guess (and it is a guess) is that you are trying to open a mis-configured remote resource like a database, web service or JMS queue. Web services are often the culprit, as the JAXWS default is to have an infinite timeout. You need to do extra work to implement timeouts.
I'm using spring-boot 1.1.3 running a web application (obviously, based on spring-web, security and more) with an embedded Tomcat.
I'm running my application on Linux (Ubuntu) machine with Java 1.7.
After couple of hours, I can see that the context is being closed without a reason. Just to make it clear, the process didn't crash and is still running, when I try to post/get a request, the client just hangs.
I'm using logback, configure with debug level as TRACE and I can not see who or why is close context is invoked.
Can someone please tell me how to detect the trigger for closing the context?
Actualy, the issue was not related directly to spring-boot but I wont change it's tag since other people might face the same scenario.
So, the unswer is the same for, How can I close a terminal without killing the command running in it?
just run your command with & at the end and than, execute disown.
We have an application which, on startup, populates it's cache from an csv. This takes about 1 minute. We thought putting an application warm up on it would eliviate the problem, but it seems like the requests specified are not being executed. Hitting the application locally will take a minute and then be instant thereafter. I tried several requests, relative (to localhost and application root) and absolute ones, to no avail. It does not work after stop/starting the corresponding app pool, nor recyclying (if there is a difference to application warm up), nor rebuilding the application.
Anyone have suggestions I could try?
Edit: The event viewer does not have anything related to the application warm up (as far as I can tell) and Application_start() is not called
if you're not seeing warmup requests in your logs perhaps you don't have them enabled in your application settings? What language are you using? (Warmup requests are enabled by default for all Java applications.)
I see entries for /_ah/warmup in my logs.
I have an NSIS installer that installs my Qt application. At the end of the install process, the installer gives the user the option to launch the application immediately.
My application uses QLocalSocket/QLocalServer to talk to other local instances of the application. (They talk to each other basically just to ensure that there's only one instance of the app running at a time.) However, on Vista, if one of the instances was started up by the installer, then other instances cannot talk to that instance unless they were also started by the installer (or uninstaller, interestingly).
The NSIS installer launches the app with the Exec command. The client tries to connect to the server through QLocalSocket::connectToServer, which fails with the error "QLocalSocket::connectToServer: Unknown error 5".
Can anyone explain this? What's the best way to work around it?
If 5 is a windows error code, it would mean access denied. Is there a way for you to change the security on this server (You would need to access the native pipe handle)?
The finish page run option has more issues than just this, the new process gets the wrong HKCU and user profile etc.
I would recommend just disabling the run checkbox on the finish page. (This issue goes all the way back to win2000 when RunAs was added)
If you really really want this run checkbox, you can use the UAC plugin, it will allow you to start a child process as the "correct" user.
Finally figured this out. The installer was running as admin (the install script said "RequestExecutionLevel admin"), and apparently it launched my app with those elevated permissions, which meant that other instances of my app running with user-level permissions couldn't connect to it. QLocalSocket/Server uses named pipes on windows, so I figure this is a windows security feature. I'm planning to work around this by using the UAC NSIS plugin, which I believe lets you run a process with user-level permissions.