The circumstances that cause this issue are not completely clear, however it has been observed that sometimes the lastChangeNumber virtual attribute decrements.
Customer's notes are:
By looking at the firstchangenumber and lastchangenumber numbers of our servers, it seems that entries are "aged out" of the external change log with some regularity.
What I see is that, for some of the servers, when entries are aged out the value of firstchangenumber is left unaltered, and lastchangenumber is recalculated according to this initial value plus the total number of entries. So, when the number of entries aged out is greater than the number of new entries, lastchangenumber goes "backwards".
What I discovered is that only happens on those servers that have had no access to the cn=changelog context during the last purge interval. As soon as I start to query cn=changelog on one server that exhibits this behavior, lastchangenumber returns to be monotonically increasing. It's like accessing cn=changelog triggers OpenDJ to keep track of the last change number.