is this a physical server or a VM ? because usually we can see delay in starting ar service in VMs.
Did it came up after delay or remains in Starting Mode only ?
Thanks for showing interest.
This is a physical standalone server, not a VM.
It remains in starting mode only, does not come up at all.
Can you think of anything here?
Toward the end of your arerror.log, you may have missed the demo license has expired.
2 of 2 people found this helpful
Here are my suggestions:
1) Ensure the java did not update and the path has changed (current path is: C:\Program Files\Java\jre1.8.0_131\)
2) Enable arstartup.log, it might give you a clue where the delay is occurring
@Jim Bruce, demo license should not stop the AR server from starting up correctly. It would only limited the AR server from performing limited transactions.
any recent Hotfix / jar updates or properties file change was done. Revert back and check.
Thanks Jason, Will do whatever you said and get back to you.
Hi Inderveer, thanks for taking interest.
Would you kindly advise me on how do I revert back.
I enabled the arstartup trace logs by adding the -t parameter after the arserver.jar entry and before the -i parameter.
Yet my AR system service remains in starting mode. I think its hanged in that mode, and refuses to budge at all.
Could you think of any other solution?
I am thinking of restarting the system but that would be the last option I would resort to.
Thanks for your valuable suggestions
I have seen multiple scenarios like this. I always wonder how to debug these kind of errors as those doesn't show up any clue. But the approach that I have used so far in resolving such issues and in most of cases it worked is as below.
1. Stop the AR Server.
2. Clean up the bundle-cache content, Active-mq folder content (if any), ARServer\Db content.
3. Restart the DB services (locking of db objects can cause issues like that).
4. Ensure you don't have any large number of groups (custom) in the Groups Form.
5. Enable the startup logs and API,SQL using debug mode as 17.
6. Start up the services.
In your case, you first need to ensure your license is applied and is valid. Then go for the suggested approach and let me know if that helps.
Based on the snippets you attached what I understand is these errors are occurring due to JMS connections (Java messaging Service). From 9.x onward, Remedy has changed to server j and it makes use of below technologies.
1. RMI : (Remote method invocation) To ensure that the changes are reflected if any admin changes are done on 1 server and needs to be sync up with other servers in server group.
2. JMS: (Java messaging service) To coordinate the communication within server group environment (which use to work on signalling bases earlier). Usually between a coordinator server and other companion servers.
With above understanding, I would also suggest you to follow a rolling restart of your environment if this is a server group environment just in case the locked connections are released and your system starts up normally.
Thanks for your detailed explanation. As I've already mentioned above, this is a standalone physical server, not in a server group environment.
Secondly, even if an invalid license is applied, that shouldn't stop the server from coming up. I hope I'm correct here?
Right now I'm quite sure that the incorrect license is applied. But since that shouldn't stop the server from coming up, I'm still looking for a solution.
Last option would be to reboot the machine.
Do you have any other suggestions on top of your mind?
By cleaning up the DB content, do you mean you delete everything in the DB folder?
Yes Edison I agree that even invalid license shouldn't stop the server from coming up,
I meant to clear DB folder content + taking restart of db services if possible. I had couple of similar issues where server won't come up and use to report similar errors of Applicationcontext.
If you want to keep backup of that folder you can do so.
Other than the message you have reported in the screen shot, have you turned on any logs (SQL specifically) to identify what it is the Remedy server is doing? I ask because that message alone doesn't mean it's not starting....there are many instances where the Remedy server can take 10-15 min's to start, which is longer than Windows will wait, which will display the message you screenshotted, but doesn't mean the server isn't still starting in the background.
During startup the Remedy server does a large amount of DB activity to load the cache into memory....so you should be able to see activity in either the SQL log or in the DB itself.