Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Request Sched to update clubusy.nsf of a cluster mate when user's home server goes down.
2 servers ServerA and ServerB
My home server is ServerA
On ServerA I enable my calendar settings to check for conflicts.
On ServerB I checked my preferences to make sure that the settings replicated. They did.
On ServerA I created an app't/meeting for 11:00 AM and saved it.
I open my mail file on ServerB and the 11:00 AM app't/meeting is there.
On ServerB I create another app't/meeting for the same day for the same time (11:00AM) to see if it would double book me.
I saved it and I got the following prompt:
The entry conflicts with an existing entry. Create it anyway?
I choose either yes or no.
I choose no.
Now my home server ServerA goes down.
I open my mail file on ServerA but get failed over to ServerB.
I create a new app't/meeting on ServerB for 1:00PM and save it.
I create another app't/meeting on ServerB for the same day for 1:00PM and save it.
I do NOT get any prompt that warns of a double book, and I have just double booked myself. Why?
The new app'ts/meetings on ServerB to not get populated to the clubusy.nsf on ServerB because my mail file does not belong to ServerB. The schedmgr task only populates calendar entries to the clubusy.nsf for the mail files that belong on the server that schedmgr is running on (ServerA).
Now, ServerA is brought back up and running.
Once the cluster replicator task starts, it will replicate my mail file with ServerB. The new appt's that were created on the mail file on ServerB are now existing on ServerA. The schedmgr task on ServerA populates the clubusy.nsf with the new app'ts/meetings that were originally created on ServerB because they now exist on ServerA. The clubusy.nsf on ServerA now replicates with the clusbusy.nsf on ServerB and now the clubusy.nsf on ServerB is updated with the entries that were originally created on ServerB
I open my mail file (still on ServerB) and create another app't/meeting for 1:00PM on that same day. I save it and now I get a prompt that warns of a double book.
I hope this clarifies how double books can occur on clustered servers.
The customer would like Schedule Manager to be "cluster aware" ie when Server A the home server goes down then schedule manager is aware that temporarily it should run on the mailfiles that have failed over to server B and update clubusy.nsf on server B.