Why does QueryChanges from ServerCommandService does not act on failover?

MIP
,
1

Documentation of ServerCommandService says: “Can be called to be notified when failover happens. Supported by Corporate and Expert product.”

I am using the Corporate 2017 version and made a failover. But no changes was returned.

So I need help to detect failover on protocoll integration, because we implent our software on a linux system.

2

I the MIP Documentation;

Milestone ServerCommandService SOAP protocol

Change [] ServerCommandService.QueryChanges(string token,

DateTime changesFrom

)[inline]

Can be called to be notified when failover happens.

Supported by Corporate and Expert product.

Could be called every 5 or 10 seconds to be able to react in a timely manor.

The result will contain the Id (Guid) of the recorder that failed over to another server. Use the QueryRecorderInfo method to get the new URL for that server.

Parameters:

token

changesFrom

Returns:

--

Are you asking every 5 or 10 seconds? Can you maybe outline how you use it?

3

Here is my Java Test-Code

for ( ; ;){
	GregorianCalendar calNow = new GregorianCalendar();
	XMLGregorianCalendar xmlCalNow = DatatypeFactory.newInstance().newXMLGregorianCalendar(calNow);
	if (lastFailoverCheck == null){
		lastFailoverCheck = xmlCalNow;
	}
	//Die empfohlen Funktion query changes funktioniert leider bei unseren Tests nicht.
	ArrayOfChange changes = service.queryChanges(token, lastFailoverCheck);
	List<Change> listChanges = changes.getChange();
	System.out.println("Changes: " +  listChanges.size() + "- From: " + lastFailoverCheck + " To: " + new Date());
	for (Change change:listChanges){
		System.out.println("--ChangeID: " + change.getId());
		System.out.println("  isRecorder: " + change.getChangeType().isRecorder());
	}
	lastFailoverCheck = xmlCalNow;
	Thread.sleep(10000);
}

“listChanges.size()” returns all the time “0”.

4

A Milestone server always works using UTC time, if the method newXMLGregorianCalendar, as you use it, does not use UTC time I believe it will explain why this does not work.

The token must be renewed from time to time, an expired token might also cause this not to work.

5

No not the solution. Failover was not detected, by giving the time in UTC.

Token has Time to live from min 1h. test time was 10 Minutes.

Here my printout (Left time is now Zulu = UTC Time):

Time To Live: 3600000000
Changes: 0- From: 2017-05-26T12:26:20.926Z To: Fri May 26 14:26:21 CEST 2017
Changes: 0- From: 2017-05-26T12:26:20.926Z To: Fri May 26 14:26:31 CEST 2017
Changes: 0- From: 2017-05-26T12:26:31.147Z To: Fri May 26 14:26:41 CEST 2017
Changes: 0- From: 2017-05-26T12:26:41.368Z To: Fri May 26 14:26:51 CEST 2017
Changes: 0- From: 2017-05-26T12:26:51.589Z To: Fri May 26 14:27:02 CEST 2017
Changes: 0- From: 2017-05-26T12:27:01.800Z To: Fri May 26 14:27:12 CEST 2017
6

Could you try to change one thing? Instead of constantly changing the time you ask with, use the same time over at least untill you actually get response. I have hunch there could be something about timing it the way you have this code..

7

Okay, now I got it. The problem was, that the Client and the Milestone Management-Server was not timely synchronized. Mileston-Server was 4 minutes back in timer.

After resync, it got two changes

Changes: 0- From: 2017-05-31T07:54:30.428+02:00 To: Wed May 31 07:54:42 CEST 2017
Changes: 2- From: 2017-05-31T07:54:41.692+02:00 To: Wed May 31 07:54:53 CEST 2017
--ChangeID: [Some GUID]
  isRecorder: true
--ChangeID: [Same GUID]
  isRecorder: true

Why I got 2 Changes for the same guid , id don’t know, but now I get changes, what is nice.

As you can see, the request time shell not be UTC. You can take a correct xml-time including time zone. (We use the same thing with alarms, what was also working fine).