[URGENT, pls] Wrong RR is triggered by Scheduler after format and resetting the RR

[SeungjeiJang]

Hi All,

Has anyone ever experienced something like this?
There are two RRs, A and B. These two RRs run the same single process at the same time. The scheduler was set up as two tasks in one schedule.

Some time ago, I formatted the RR B. After the format, its hostname was changed, and the RR name was also changed. So I went to the scheduler and reset the task setting by matching the new RR name with the process.

The current issue is that when task A is executed, RR B is running, and when executing task B, an exception occurs saying that the RR B is offline. (The both RR B I mentioned above have the exact same name)

There seems to be something logically broken in the way the format and the new RR is connected.

I deleted the schedule and tried to recreate them, separately this time, but it didn't work.

What can I do to initialize this broken logic?
Should I’ve done the clean reboot for all BP components inluding App Server?

Thanks.

[expertcr]

I see your other question for RR duplicated in the Control Room; maybe it is related; please try to Retire the problematic RR and return after testing the scheduler to start the correct RR.

[Walter.Koller]

Maybe there is some confusion.

A Schedule can have several tasks.

Each task is executed sequentially in a workflow define by final state (On Complete / On Exception)

A task can have several sessions that are started in parallel


Could you provide some screenshots maybe?
For me it was not clear what actually happened. eg 
"its hostname was changed, and the RR name was also changed."
"The both RR B I mentioned above have the exact same name"

"I deleted the schedule and tried to recreate them, separately this time, but it didn't work."
What exactly?
RR B is supposed to be online but always fails with the message BP thinks RR B is offline?
If the RR was moved to another domain ("its hostname was changed") other than the one BP is located in, then it might look fine in Control but BP might not be able to directly communicate with the RR.
Did you set your RR registration settings to either RR registration to short name & communication to  FQDN, or use FQDN for registration & communication?

[SeungjeiJang]

@Walter Koller Thank you for your comment.

To avoid confusion, let me explain in more detail.
This is from the email that I sent to Global Support.

Initially, the schedule was set as below and working fine.

1. Schedule A (7:30 AM)
   1. Task 1
      1. Process (Preparing) + Runtime Resource A (RR.A)
   2. Task 2
      1. Process (Preparing) + Runtime Resource B (RR.B)
2. Schedule B (7:40 AM)
   1. Task 1
      1. Process (Main) + Runtime Resource A (RR.A)
   2. Task 2
      1. Process (Main) + Runtime Resource B (RR.B)

Process (Preparing) : It is a process that checks RR’s status such as availability, connectivity etc. prior to run Process B.

Process (Main) : It is a main process.

For some reason, they formatted RR.B and re-installed BP.

After that, RR’s name is changed as the PC’s name changes.

So, they retired the RR.B and re assign the new RR, RR.B’ by replacing the old RR, RR.B

Like this.

1. Schedule A (7:30 AM)
   1. Task 1
      1. Process (Preparing) + Runtime Resource A (RR.A)
   2. Task 2
      1. Process (Preparing) + Runtime Resource B’ (RR.B’)
2. Schedule B (7:40 AM)
   1. Task 1
      1. Process (Main) + Runtime Resource A (RR.A)
   2. Task 2
      1. Process (Main) + Runtime Resource B’ (RR.B’)

After this, the issue has started happening.

When the Task 1 is triggered by the Scheduler A and B on RR.A, RR.B’ is triggered.

When the Task 2 is triggered by the Scheduler A and B on RR.A, RR.B is triggered. (and gets an error in the Schedule Log says “RR.B is offline”) <- because RR.B is retired.

It seems like RR.A in the schedule is addressing the new one, RR.B’

And RR.B in the schedule is addressing the retired one, RR.B

So, I guided them to completely remove the existing schedules and re-create them.

Here’s the new Schedule.

1. Schedule A (7:30 AM)

1. 1. Task 1
      1. Process (Preparing) + Runtime Resource A (RR.A)
   2. Task 2
      1. Process (Main) + Runtime Resource A (RR.A)
2. Schedule B (7:30 AM)

1. 1. Task 1
      1. Process (Preparing) + Runtime Resource B (RR.B’)
   2. Task 2
      1. Process (Main) + Runtime Resource B (RR.B’)

​Thanks.

[Walter.Koller]

@SeungjeiJang many thanks for your explanation and more details.

The new schedule looks much better to me as the dependencies are better fulfilled
(1. task: check availability, 2. task execute)​

We didn't experience any similar situation to what you described.
Several of our RR have been wiped and installed again. The configuration always stays the some (IP, hostname, ...) and BP didn't even notice there was a chance.
We also did some replacements, removed one RR and added another instead. This should be similar to your case as BP identifies RR by its name. If the name changes, like in your case, it will be a new RR. 
My guess would be there is an issues in your network.

I would be happy to help further but I am afraid it could become to technical for community thread in parallel to BP support. 
Maybe to check if those RR are work as expected when using RR web interface, telnet connection, ping, nslookup 
But probably you already did those test ;)