TT 7.0.5 : Err : REP: TT16133: Peer signals change in its configuration

Question

Hello there,
We've encountered a replication problem ( TT16133 ) and would like to get more details about its cause, severity, and suggestion to mitigate it .
Configuration : TimesTen Release 7.0.5.0.0 (64 bit Linux/x86_64)
By looking at the context around the time these errors were reported, it appears we were doing a ttMigrate -c on several datastores, including the one which threw the error.
Primary datastore has the following line in its tterrors.log :
05:02:17.47 Err : REP: 4592: <datastore>:transmitter.c(5079): TT16133: Peer signals change in its configuration
Replicated datastore has the following lines in its tterrors.log :
05:02:06.66 Err : REP: 20483: <datastore>:receiver.c(1661): TT16154: Failed to check for replication schema changes
05:02:06.66 Err : REP: 20483: <datastore>:receiver.c(1661): TT6003: TT6003: Lock request denied because of time-out
Details: Tran 3.690152 (pid 20483) wants S lock on rowid 0x000000000083f8d0, table TTREP.REPLICATIONS. But tran 32.18086 (pid 6579) has it in U (request was U). Holder SQL (call ttRepSchemaInfo(1);) -- file "table.c", lineno 25438, procedure "sbTblNextActiveTuple()"
05:02:06.66 Warn: REP: 20483: <datastore>:receiver.c(1694): TT16155: Temporary failure to access replication configuration
The replication daemons on both sides were successfully up and running for few hours already, as well as their replication schemas being successfully uploaded onto them, at that time.
Thank you,
Ionut

Answer 1

It is very likely that the ttMigrate -c is the culprit. That operation will place some locks on system tables and it looks like they are held for a not insignificant time. While those locks were held, the repagent tried to access the same tables to check if any schema changes had occurred and was not able to do so. The error is transient and should not cause any problems and can be safely ignored. it is possible that this could be a bug since:
1. It maybe the ttMigrate is holding locks for too long and could releae them sooner (we'd have to investigate to see that is the case).
2. A failure to check the schema change status on one peer should probably not result in an indication that the schema has changed on other peers. Again, we'd have to look into this.
If you are concerned about this then you should open an SR so that further investigation can be done.
Regards,
Chris