Bug 3475 - Logging Service persistence strategy scalability issues
Summary: Logging Service persistence strategy scalability issues
Status: ASSIGNED
Alias: None
Product: TAO
Classification: Unclassified
Component: Logging Service (show other bugs)
Version: 1.6.6
Hardware: All All
: P3 normal
Assignee: J.T. Conklin
URL:
Depends on:
Blocks:
 
Reported: 2008-10-27 13:53 CDT by J.T. Conklin
Modified: 2008-10-27 13:53 CDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description J.T. Conklin 2008-10-27 13:53:12 CDT
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.