The engineer asking the question is correct that the two methods of IFS (near real time) replication with iCluster are journaled and non-journaled replication. The other method is using a periodic snapshot replication using a *RFSH replication group type. (not usually the best choice for millions of objects but should be considered and eliminated if it is not applicable) For IFS objects that are created, stored and do not change, non-journaled IFS object selection can be a good choice. On occasion I have heard of applications that do go back and touch the attributes of documents after creation which causes the objects to be exceptions in a sync check afterwards. Watching for that behavior may be key in your decision which method to use. (Some customers thought they were not changed and surmised the exceptions were because iCluster replication was inaccurate. When investigated, the objects were indeed modified seconds after they were created but had already been replicated so the change was not registered by non-journaled replication.) Remember that non-journaled replication tracks actions like creation, renames, moves and deletions so if your IFS path of objects only have these type changes they are a good candidate for that setting. You do have to experiment if your first configuration choices do not result in your cleanest operation. Frankly, the journaled IFS selections work great and hedges your bet that the objects in the IFS folder are touched only once. Attribute and content changes are automatically replicated if they occur.
The caveat (when using this option) is that the journal attributes should be modified to allow 'Journal object limit' to *MAX10M to prepare the journal to receive changes for objects above the default limitation of 250K. Then also consider if the 10M limit will 'EVER' be reached in the current configuration. If there are chances that it may be reached, consider splitting the paths into multiple data journals. Don't forget to change each journal attributes to the *MAX10M setting.Notice also the HELP note included with the CHGJRN command:Runtime performance concerns should be considered whenchoosing this option (selecting the *MAX10M option). With this new attribute, there is an opportunity for a greater number of objects journaled to one journal. Thus there is a potential opportunity of more objects that can be actively changing at the same time which can affect journal runtime performance. Therefore if the frequency of journal entries being deposited to this one journal is causing runtime performance concerns, then a betteralternative would be to split the journaled objects to more than one journal. In my opinion, there is a low risk in the case we are discussion but each situation should be considered to avoid update contention. Highly active IFS paths do exist and careful consideration when using this option in the Library.Databasefile storage area is warranted.
Finally, when there are millions of objects, you want to consider if there are single threaded components in your replication design and how to mitigate them.
I hope you find that discussion helpful. You can ask questions in the Forum related to a post or start your own discussion. If you want me to proof read a post that you think others will find helpful, feel free to send it direct to my email address. I would be happy to help you write it or can even post it on your behalf if you prefer.
77 4th AvenueWaltham, MA 02451 USA
Rocket Support Community
All Support Offerings
About Rocket Software
Training and Services
Forum Terms and Conditions
Contact Forum Moderator