Last night, Genii Software released CoexLinks Fidelity Version 3.65. This release incorporates three major updates as well as bug fixes and minor enhancements since the previous release. Version 3.65 is currently available for Windows 32-bit and Windows 64-bit, and it is planned that the Linux version will be available next week.
Update 1 - 30% performance enhancement
With a complete code review and numerous changes to streamline, we have achieved a 30% or better improvement in email processing. While most customers won't see a lot of difference because the performance was very good even before these changes, those with heavily loaded systems may see a decrease in bottleneck situations where messages where sometimes backing up in the mail.box database. This performance enhancement is separate from the multi-processing mode below which can also have large performance benefits.
Update 2 - Support for Multiple Message Store databases
Customers using the Message Store feature extensively are now able to specify multiple databases, and CoexLinks Fidelity will cycle through the Message Stores to distribute the load. While a single Message Store database is enough when the feature is implemented for only rare message formats, multiple Message Store databases make sense for customers who configure the feature to trap a larger percentage of emails, or who use encrypted mail extensively.
Update 3 - Multi-processing mode with Enhanced Crash Protection
It is quite common for a hub or gateway server to have multiple mail.box databases to allow smoother, faster processing by the Router task. In this mode, the CoexLinks MsgProc task can spin off a separate process for each mail.box, allowing parallel processing and preventing bottlenecks if one mail.box gets backed up. In addition, the multi-process mode allows enhanced crash protection so that if a badly corrupted rich text message manages to crash the rendering engine, the process will detect the crash, log the message which caused the problem and shut itself down. The process manager will then detect that the process is gone and will restart, skipping the offending message. Note that this is extremely rare, but even if it happens in one out of a million messages and a customer has three hundred thousand emails a day, the crash could theoretically happens once every 3 to 4 days. With this feature enabled, processing will go on without pause, and the offending message can be identified and analyzed so that a similar crash can be avoided in the future.
The following console messages show how the multiple process happens. Since we have no messages we can find that currently crash the process, no matter how badly corrupted, we had to add a debug flag that allowed us to create a null pointer for a specific message so we could show what happens when it occurs.
Copyright © 2014 Genii Software Ltd.