I wonder if anyone has come across this before and can help me overcome the problem.
We have a series of servers using a ‘hub’ methodology. Our ‘hub’ server replicates every 10 minutes with all the other servers in turn and they all replicate fine.
However we have encountered a problem since we started forcing our discussion group databases to replicate to our intranet server when the ‘new posting’ email agent runs. we are using a Call db.replicate"CN=server/O=domain") call.
We do this so that we can be sure that whenever someone recieves an email about a new posting the document is always on the intranet server as we include a link to the posting in the email.
What we have noticed is that when the agent has run the system then decides to skip its replication to that server believing it has already done it. This can cause us to not update the live server with all the other changes for up to an hour, which can be a problem.
Can anyone suggest anything to remedy this problem?
Thanks
Paul
Subject: RE: db.replicate stops general replication
I see two ways you could go with this.
One, force more frequent replication of the application in question. The replication settings do let you have different tiers of priority in replication, so that some databases can replicate every hour, say, and others every half-hour. Or you could write a scheduled agent to force replication on the hour the same way you do now on event.
Alternatively, you might delay sending out the mail notices until the information is available on the intranet server. You could do this most simply by having the intranet server send the notices out itself in a “when docs created/modified” agent. This assumes the server is set up to route email, which not all servers are.
Subject: RE: db.replicate stops general replication
Andre
Well I must say that I am shocked by the response :-))
I felt sure that someone was going to tell me that I was doing something wrong or had something mis-confirgured!!
I can’t believe that one database calling for a ‘personal’ replication can lead the server to believe that it has replicated all the databases and therefore not bother trying !!
Or is it the case that when the db.replicate is called the servers ‘last replication between A and B’ time is changed and that is what is stopping the ‘general’ replication taking place ?
Thanks for helping me clear this up
Paul
Subject: RE: db.replicate stops general replication
Ah. It wasn’t clear from your original question that replication was failing to occur on all databases on the server – I thought you were just saying that the one database that you replicated by “force” was delayed in doing further replications.
In any case, I haven’t heard of this happening before – but I wouldn’t necessarily. I would echo Paul’s suggestion that you contact IBM support, but I tend to just assume people are doing that anyway, and when they come here they’re looking for workarounds. So, I was ready to take your word for it that there was a problem, and the workaround is what I addressed.
Even if it’s not practical to send the email from the server that you send people a link to, you could still delay the emails on the originating server by sending them in a scheduled agent that sends email only about documents that are old enough that we’re sure they replicated, and uses UpdateProcessedDocument on those, effectively “throwing back” the others to get riper and catch them on the next pass.
Subject: RE: db.replicate stops general replication
so let me try and understand, your hub server replicates on schedule with your other servers every 10 minutes. If you new posting agent runs it forces a replication of 1 database. When this happens the scheduled replication stops working for up to 1 hour? If that’s the case then this makes no sense because the servers should replicate at least every 10 minutes via the schedule from your hub server. Please let me know if my understaning is correct. If so, this could be some sort of bug and you should report it to IBM. To solve your problem you could cluster servers A and B so that new postings get replicated immediately after getting created. If you are replicating ever 10 minutes anyway, clustering is the way to go.
Subject: db.replicate stops general replication - clarification
Paul
I nearly explained myself right 
Correct - hub server replicates with about 7 other servers every 10 minutes.
Correct - agent forces replication of one database only.
Correct - this stops all replication.
Incorrect - this stops replication for one hour.
Explanation - when the agent forces the replication it seems to stop the next scheduled replication (the server thinks it has replicated) but what sometimes happens is that for four or five times on the bounce every 9 minutes someone creates a new posting - hence the replication keeps getting put back and put back until there are no postings for a full 10 minutes and then the replication works correctly.
Our ‘administrator’ tried clustering but didn’t like it so that is not a goer.
I hope this clears things up.
Cheers
Paul