This type of plugin errors occurs while there are something wrong in the plugin parameters defined inside the pluginsvr.xml file. Also if they are not defined inside ar.cfg file.
Define the plugin entry in ar.cfg file with FQDN, also check the same in the windows host file, whether DNS entries are there for FQDN against IP and hostname.
Also cross check if port is not blocked at firewall which is using by this plugin. Along with that take a restart of ARS service and check the arjavaplugin log file whether this particular plugin is loading or not.
Moreover Experts will suggest you to the right way.
1 of 1 people found this helpful
in the attached pluginconfig.xml file i see the port as 9800 , but in your example i see port as 9999.
Port should be same as that of pluginconfig.xml file.
Many thanks for taking interest in this.
Yes, I can affirm that my ar conf has 9999 and pluginsvr_config.xml has 9800.
I have been going through existing literature on Communities & Docs but there are conflicting opinions about what you have suggested above.
For example, please have a look at the following link.
https://communities.bmc.com/thread/172742?start=0&tstart=0#736839 (please check what Carl Wilson's Blog / Carl Wilson has to say here on ports 9800 & 9999. I am assuming he’s asking to change the port on pluginsvr_config.xml to 9999, since 9800’s already there)
Configuring BMC Remedy Approval Server with a separate plug-in server instance - BMC Remedy Action Request System 8.1 - … (Check our steps no 1 and 2 here, and also check out the first entry in the comments)
Another question that pops in mind is - why is this causing trouble all of a sudden when things were working just fine till now. This is happening with CRQ and only with one particular person, and with approvers section.
Again, do you think there are any issues with FQDN (though I am now fin the opinion FQDN shouldn’t matter as much, fingers crossed)
Do you you have any guesses on the latter question on this happening all of a sudden?
Also, I am assuming I need to server restart after making changes to either pluginsvr_config.xml or ar.conf, am I right?
Thanks again for your suggestions. I still need them
Thanks for the input, sorry i miss the point that its only problem with one user.
Can you try deleting that user and re-creating it.
Million thanks for responding so quickly.
Yes, I can certainly try that - deleting the user and recreating it.
Now, I need to tell you, that since this issue is in production, and the user is a VIP, I will first create mirror profile of that user in production and try raising CRQ & see how things go. If CRQ proceeds just fine, then maybe we can say that we need to create a new profile for that user.
Also, would deleting the user ( esp a VIP) cause him to lose all data / activities he’s been doing in the past. I mean maybe he has created tickets in past which are quite important. Does he stand to lose it all? Please advise on this.
Just one more thing - May I ask what makes you think deleting & recreating the user will help? Do you think the user/ people profile has been corrupted?
I find myself thanking you again
Would you kindly point out how can I reach the windows hosts file?
Actually we are on Linux. So which file should I check?
Thanks for taking interest in this
Thanks for the update.There are 2 possibility.
1) User corruption at Db level, as for all the user it working fine.
2) Or User cache issue.
For hots file in Linux the location is /etc/hosts
Hope this trick help you.
Thanks a lot, Alok.
I’ll try these & get back to you.
Thanks for coming back.
We restarted the java plugin yesterday and noticed that the PID for approval changed, and the same new PID was reflected in at.lck.390608
However, we are planning to restart AR in off-business days like coming Saturday.
Apart from this, is there anything I could do?
I checked the hosts file yesterday.
There are many entries but the entry pertaining to the prod server which I am concerned with goes like this →
IP_Address prodserver1.fqdn.com prodserver1 itsm_branded_app_name
Also, every other entry in the hosts file looks like this, except that they don't have the "itsm_branded_app_name" attached at the end.
So, to me, looks like the host file configuration is all right.
Ergo, its shouldn't matter if its PQDN or FQDN in the ar conf file, since it would be picking up the FQDN from the hosts file anyways.
May I ask for your thoughts on this?
Besides, I thought maybe the problem lies with that particular user, since that user joined the organization only 6 weeks ago, and maybe this is the first he's raising a CRQ.
So, I enabled the client side logs and server side logs, and I asked them to repeat the procedure of raising the CRQ.
While doing that, one other who was on call, said he saw the same error while he went on to check the "Show all approvers" on Change Console.
I am now thinking, maybe I need to check if this issue is occuring on all servers.
Also, maybe I could check using User Tool.
We did not get the opportunity to restart the AR server yesterday, maybe next week.
Please revert your opinion.
Thanks for your suggestions
It seems alright with your host file.
If you do have the user tool then yes you can try over this too. And if this is with the single user did you ever check on any other machine by using his remedy ID ?
Try to perform below steps if that can help you:
-> try by deleting the data from AR System Searches Preference form for that user.
-> Delete the record from AR System User Preference form for that user.
Moreover Sidhdesh Punaskar can give you best suggestions about approval related issues.
Is this person individual approver or part of group approval?