Question
Pegasystems Inc.
JP
Last activity: 6 Apr 2019 22:41 EDT
'Another Handler' error sometimes halts the automation, sometimes doesn't
Hello!
I have checked the past post closely related to this error (https://community1.pega.com/community/product-support/question/exception-windows-adapter-another-handler-already-registered), but the issue I have been facing is slightly different.
I have 2 occuerrences of the 'Another handler already registered for messages from process XXXX' error.
Older occurrence was when a given Webadapter was started to launch an external WebApp and the target process (IEXPLORE.EXE) is attached to WindowsProcess object. This error used to halt the automation completely.
The recent one is when link between WaitForCreate(WFC) of a webpage and pause that is on the True port of WFC is executed. This time it allows the automation to run without any problem. (Refer the attached error_DoesntStopAutomation.txt for error log).
I know that Runtime allows the show to run with few exceptions that it can ignore exceptions, and halts the execution in case of an unignorable error. My question is how is that decision made, especially when its the same kind of error?
(Will upload error log snippets for both errors shortly)
***Edited by Moderator Marissa to update SR Details***
Pegasystems Inc.
US
Without examining your solution and your logs, I could not say for certain, however the exception in the prior post is caused by having two adapters effectively hooking the same instance of the application. Don't do that and you should avoid the error. The errors that get hidden by that setting in the RuntimeConfig (SuppressAdapterExceptions) are ones caused by the adapter and not by the automation. If you have an exception happening because of an automation step, then it is not an adapter exception.
Pegasystems Inc.
US
I do believe this is actually a product defect. I would suggest that you open an SR to have support collect logs. It seems there may be a bug whenever an adapter is restarted and the PID is re-used. If you do open an SR, please include the number here for tracking purposes.
Pegasystems Inc.
JP
Dear Thomas,
I understand. I missed out on mentioning this that I have observed the PID being re-used, especially for the iexplore.exe process that is created when the adapter is restarted immediately after stopping (it might seem like a weird thing to do, but thats how its being done for the current project).
I would open an SR and get this behavior checked. I would share the logs in here, too.
Appreciate your kind support and time to answer this.
Best regards,
Mangesh Walhe
Pegasystems Inc.
US
Thanks @MangeshWalhe! I've updated your original post with the SR details and linked this PSC post to your SR to help out the Engineer who picks up your SR!
Pegasystems Inc.
JP
A correction and some more information regarding this problem.
1. The PID being reused is when the robot DOES NOT halt. Its a screen which checks out a caseId and then gets destroyed. The same PID is being used for possibly the same checkout screen and then the error. In the Javascript visible internally while debugging we could confirm that its referring to the penultimate caseId processed on the same machine.
2. A slight different behavior is observed for the case where the robot is halted. The WebAdapter tries to stop the IEXPLORE.EXE process attached to it and logs that 'Process IEXPLORE.EXE with id 7804 has been destroyed.' followed by the 3 lines:
'Stopped Process - name: IEXPLORE.EXE' >> 'Adapter SearchF2 failed to stop process 7804' >> 'Adapter stopped'
Then further below the adapter is started again and while attaching the IEXPLORE.EXE with a new PID (6992) we get the error.
I will upload the detailed logs for these as soon as I get them approved by Client today.
Pegasystems Inc.
JP
Some inputs a questions further in this regard:
The case wherein the error occurs when we try restarting the WebAdapter, we found that:
- Webadapter starts
- WindowsAdapterBase.StartProcess is executed as part of 'Adapter reparenting'
- A WindowsAdapter starts, and it in turn initiates IEXPORE.EXE with the URL configured in WebAdapter properties
- Once the 'WM_OS_PROCESS_CREATED received' event takes place, WindowsAdapter tries attaching the IEXPLORE.EXE process to WindowsProcess object.
While executing step 4, we get the error.
In an effort to stop the earlier WebAdapter process/instance, we also observed following log output:
- WindowsAdapter (spawned in the same way as explained in 1, 2 and 3 above) for the preexisiting WebAdapter tries to stop the IEXPLORE.EXE and logs that it has stopped the process.
- On the next line it logs as Adapter failed to stop the target IE process (recognized by the PID)
- WebAdapter is stopped nevertheless.
I would request for some insight on:
- How does the product maintain the Handler repository/registry?
- Why the WebAdapter stops even when it has failed to stop the process that it had spawned?
Any help/input in this regard will be appreciated and welcomed.
Thank you,
Best regards,
Mangesh Walhe
Some inputs a questions further in this regard:
The case wherein the error occurs when we try restarting the WebAdapter, we found that:
- Webadapter starts
- WindowsAdapterBase.StartProcess is executed as part of 'Adapter reparenting'
- A WindowsAdapter starts, and it in turn initiates IEXPORE.EXE with the URL configured in WebAdapter properties
- Once the 'WM_OS_PROCESS_CREATED received' event takes place, WindowsAdapter tries attaching the IEXPLORE.EXE process to WindowsProcess object.
While executing step 4, we get the error.
In an effort to stop the earlier WebAdapter process/instance, we also observed following log output:
- WindowsAdapter (spawned in the same way as explained in 1, 2 and 3 above) for the preexisiting WebAdapter tries to stop the IEXPLORE.EXE and logs that it has stopped the process.
- On the next line it logs as Adapter failed to stop the target IE process (recognized by the PID)
- WebAdapter is stopped nevertheless.
I would request for some insight on:
- How does the product maintain the Handler repository/registry?
- Why the WebAdapter stops even when it has failed to stop the process that it had spawned?
Any help/input in this regard will be appreciated and welcomed.
Thank you,
Best regards,
Mangesh Walhe
(P.S. I have received few detailed logs for this regard. Will upload them for sure)
CollabPartnerz
IN
Below link might help you
https://collaborate.pega.com/question/pega-automation-scheduling-service-doesnt-work-expected
Pegasystems Inc.
JP
The related SR (SR-C52490) has been resolved as 'Resolved- Future Release', (I am unable to to check the status for SR-C52319.)
Yet, I want to know the following:
- What was the result of SR-C52319?
- What was the root cause of the problem? Whether the problem occurs when Automations are written/ Project is designed in a particular way? In short, what triggers the problem?
- Which version of RAS/RAR is this planned to be released? Or has it already been released?
- Any suggestions for workaround untill upgrading the RAS/RAR in use.
Since I do not know any of the above, we are still stuck with the problem, and are unable to even bypass it gracefully.
Pegasystems Inc.
US
1. SR-C52319 was resolved due to stagnation. The effort required by the customer was not proportional to their desire to resolve the issue since for them it was so rare.
2. As I understand the issue, it is not an automation issue and insytead a core product issue where it is unable to handle a process ID being re-used during a runtime session.
3. I do not know. I would contact support and they should be able to provide that information.
4. There is no way to workaround it. You can restart Runtime if you detect the issue, but there's nothing you can do to the current Runtime instance should it occur. I would recommend that you open your own SR to have the issue looked at for you specifically.
Pegasystems Inc.
JP
Thank you for a detailed reply Thomas. Clears a lot of things.
I will get in touch with support to get the release related information.
Pegasystems Inc.
JP
As it turns out,
- SR-C52490 was closed as the issue was being handled using SR-C52319.
- There was a CR against SR-C52319 as well.
- SR-C52319 was closed due to stagnation, along with it the CR for the engineering team as well.
- So there is nothing with which we can be sure that the issue has been resolved and released.
So although we have SR-C52490 been closed as 'Resolved-Future release', the issue might still be there. There is a faint possibility of the issue having been resolved due to other fixes and modifications in the latest release of RAR/RAS, but we have to check it.
I think I will want to keep this thread open so that we have a logical closure.