RPT adapter "unavailable" in RQM on Windows 2003
All,
When configuring RPT as a service on a Windows Server 2003 server and starting it, RQM still shows the adapter as "unavailable". I noticed that when the service is started, 3 services show up in the services list in task manager: RPT-RSM_RQMAdapterService.exe, eclipse.exe, and javaw.exe. Javaw.exe uses 50% CPU constantly and about 27 MB of memory. When I shut down the service, eclipse.exe and javaw.exe remain running until I kill them through task manager. When I set up and run the RPT adapter for RQM on my local Windows XP machine, everything works properly. I have tried the following steps to attempt to narrow down the cause of the problem, but now I am stuck. 1) Run the adapter from the console under my account (which is an admin on the W2K3 server) - success 2) Run the adapter from the console (by using pstools -i -s cmd.exe and confirming it's the system account using whoami) - success 3) Modifying the service to "Allow service to interact with desktop" - fails as above 4) Modify the service to run under my domain account (admin on the server) - success 5) Modify the service to run under a domain account (not an admin on the server, just in the users group) - fails as above. I tried using procmon on the services, but did not find anything unusual. When the adapter shows as available in RQM, I notice that javaw.exe uses about 138 MB and 0% CPU. Any help would be appreciated. |
9 answers
|
One other thing I forgot to mention: the adapter.log file is never written to in any of the cases above marked failed. It appears to me as if the javaw.exe is getting in a continous loop and never gets to the part of the program that writes to the adapter.log file.
|
Your problem reminds me of this issue:
http://www-01.ibm.com/support/docview.wss?uid=swg21321703 There is a folder under your RPT install directory named "RPT-RST_RQMAdapter". It contains the adapter.config, adapter.log and some other files which must be accessible to the RPT adapter code. I believe what you are seeing is the fact that the service running as the local system account is unable to modify the files under this directory. This will cause the issues you are seeing. To fix, right click the folder "RPT-RST_RQMAdapter" and select properties. Go to the security tab and add "Everyone" to the access list for this folder. Give "Everyone" full control access for this folder. Starting with RPT 8.1 this should be done automatically for you. I'm guessing your using RPT 8.0.x. Or you did an update from 8.0 to 8.1, as opposed to a clean install of RPT 8.1. Also, you might want to look at the adapter console in RQM and make sure you don't have multiple adapters listed for this machine. That was also a side effect of the file permissions issue. If you do have multiple adapters, then first stop the adapter then use the delete button in the RQM adapter console to delete any adapters for this machine. Also, on the RPT machine modify this file "...RPT-RST_RQMAdapter\config\adapter.config" and remove the line that starts with DO_NOT_CHANGE_ADAPTER_ID. Then restart the adapter. Let me know if this helps. |
|
kurtism,
Thanks for the response. This is a fresh install of RPT 8.1.0.3. I double-checked that Everyone has access to the RPT-RST_RQMAdapter folder and everything underneath it. I also removed the line DO_NOT_CHANGE_ADAPTER_ID and then started the service. Same result. The adapter console in RQM only lists the one adapter for the machine. I suspected that this was a permissions or group policy setting, but when I run the adapter through the console window (I started the console window as the local system account and the adapter works fine that way) that adapter works properly. It's only when being run as a windows service with the local system account that things seem to be failing. Thank you very much for your suggestions. |
It's my impression that the RPT adapter starts it's own eclipse/RPT instance in the background, owned by SYSTEM. That explains the eclipse.exe and javaw.exe that you're seeing, but not why java is consuming all your CPU.
|
|
verronep,
I'm pretty sure it's a file permission issue. There must be something special about Win 2k3 services or something with your machines security policies which is preventing the service from writing to certain files. One thing I'm not sure if you tried yet is to create a local user account for the adapter service to run as. That user shouldn't need to be in the admin group. I should have some more time to try this on my Win 2k3 server machine tomorrow. I'll let you know my experience once I've tried it. FYI... I'm a developer on the RPT product and wrote the RQM RPT adapter service. So, I'm curious to understand this issue more and figure out a solution that works for you. |
|
I tried using a domain account that is not an administrator on the W2K3 server as the service account. At first I got a message that the service started and then stopped. In the event log, a Win32 Exception was logged saying that a file could not be found (it turned out the account did not have access to the jdk folder). I then granted the domain account full control over the SDP folder (matching the SYSTEM account permissions) and everything worked properly.
I also did this with a locally created account (rptuser) and granted full control over the SDP folder and everything worked as well. So now we're down to some difference between the system account and any other account. I will review group policy permissions again and see if I notice anything and let you know. |
|
I tried this on my W2K3 EE SP2 server and did not experience the issue you experienced. I was able to successfully run the adapter service with the system account and a local user account and in neither case was I required to change any file/folder permissions (i.e. the SDP folder).
I still surprised the local user works and system doesn't since the system account has higher access rights then local users. Seems like the best thing for you to do would be to continue using a local system account. Hopefully is acceptable in your environment. If you want to keep investigating, the next thing I can think to do is to enable some more debugging in the RPT code. For your situation here's how that can be done. 1) Open RPT on a new workspace. 2) Go to Windows -> Preferences -> Logging -> Loggers and look for the com.ibm.ration.test.lt.rqm.adapter entry. Set it to ALL. 3) Close RPT and modify your adapter.config to use the new workspace. 4) Open the properties dialog for the service and in the startup parameters field enter "-debug", omit the quotes. 5) From the service properties dialog hit the start button. 6) Wait a while and see that the adapter isn't available. (roughly 20 seconds). 7) Stop the service. This will cause the service code to write some extra debug to the Windows Application Event log. It will also cause the RPT java code to write some debug messages to the workbench log file. The workbench log can be found under the workspace in the .metadata directory. The file name is .log. I appreciate the information you've provided. If anyone else encounters this situation, I'll be sure to get it documented in RPT. |
|
Kurtis,
Thanks for all your help with this issue. I appreciate it. I was able to get the RQM adapter for RPT working with the local system acount - I uninstalled RFT 8.1.0.3 from the machine and it started working. I followed your steps below to create the .log file and in there I noticed many messages that looked to be tied to RFT so taking a guess I uninstalled RFT and now everything works. I have the same setup (RFT 8.1.0.3 and RPT 8.1.0.3) installed on my Windows XP machine and didn't have an issue so I still don't have any idea what the true difference is (though the install order was different on the two machines - maybe I will try that on a spare machine as an experiment). I have the .log file with RFT and RPT installed, as well as a .log file with just RPT installed I can send you if that is of any interest. Thanks again for all your help. Paul |
|
Sure, you can email me the .log files using the email button in the forum. It still doesn't make much sense. If the issue was caused by the fact that RFT was installed, you would think the same problem would happen for other users. Not just the local system account.
In either case I'm glad it's working for you now. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.