Please report new issues athttps://github.com/DOCGroup
At IDE, we encountered scalability problems with the Logging Service due to the persistence strategy API. Currently, the Logging Service uses a ACE_SYNC_RW_MUTEX as a lock around all operations. This generally worked well, as logging new records needed to be serialized anyway. However, we discovered that rwlocks were not "fair". On some platforms, a thread could be blocked indefinitely while others received and then processed new log messages. In the IDE repo, I changed the log to a ACE_Token, which addressed this problem. A larger problem, which I did not have time to resolve, was that a long running query() (or match(), or similar operation) essentially blocked the log service from recording new log messages. This suggests the logging service needs more than a simple change of logging primitive, but rather to use a transactional semantics that will allow simultaneous inserts and queries. This may be difficult to do for the default strategy, but it's concrete "transaction" object could simply wrap a rwlock or token with no loss or benefit. But dynamically loaded strategies that use a RDBMS back end, could use native transactions and would benefit from the added concurrency and scalability.