Strange Orchestrator client behaviour

[mbrkic]

Hi,

Starting earlier today my Orchestrator client started not working. When I log in with my user name it goes through all the loading as always but when the screen finally opens it is just white and the j2launcher.exe process keeps running at 100% of CPU.  This seems to have followed trying to create a new folder under "My Workflows" folder.

I am launching the client through a browser, and I tried clearing the browser cache. Also, there is no load on the server after the initial connection. Nothing obvious in the logs either.  The server is version 7.1.0.

Another interesting thing is that I can log in as another user, but I cannot see the workflows folder with all the workflows from my broken user, which is the account I use for most of the workflow creation and editing.  When I log in as another user it behaves ok until I try to access the workflows from the broken user, at which point it hangs in the same manner (client unresponsive and using high CPU).

The scheduled tasks which are all running under and from the workflows folder of the broken user are still running since I can see an external database getting the new entries from the periodic workflows.

I tried restarting VCO from the "Control Center" and even rebooting the vCO appliance but without any effect.

Any pointers as to what the issue might be would be greatly appreciated.

Cheers,

Milos

[iiliev]

Hi,

Have you also checked the client logs (files vso.log, vso.log.1, ...) that are located in the same folder as the downloaded JNLP file?

[mbrkic]

Hi,

thanks for the quick note.

I did look at it. Nothing special in there either. It ends with:

2018-02-26 18:51:55.712-0500 INFO  [VSOApplicationFrame] Server version:7.1.0.4262825, instance id: 6a1168c6-1c65-4296-97eb-b1997cfb98e3

2018-02-26 18:51:55.962-0500 INFO  [Application] Finish loading...

Cheers,

Milos

[mbrkic · Accepted solution]

Hi,

I resolved this by looking into the vRO database and noticing that the entry for "MyWorkflows" folder in the "vmo_workflowcategory" table had its own id in the "parentcategoryid" column. I have no idea how or why this got to be. Since this is a top level folder its "parentcategoryid" needs to be NULL. Once I updated that record everything went back to normal.

I had an open SR for this, and after resolving it I had them look at the database and validate it, as much as they could. They said there was no indication of any other corruption.

So case closed.

Cheers,

Milos