BIND 10 #2790: Lettuce tests timing & missed messages

[BIND 10 Development]

#2790: Lettuce tests timing & missed messages
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:
           Component:  Unclassified  |  Sprint-20130319
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  Core          |              Defect Severity:  N/A
Estimated Difficulty:  9             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 jelte]:
 > update3: we have come to the conclusion that it is the threading that is
 the culprit here; the interprocesssynclock is not thread-safe; I have
 experimented with one of the branches of #2198, and that one appears to
 fully solve the issue.
 >
 > I therefore propose to finish up #2198, and close this one.

 If that (= we'll need to take care of both inter-process and
 inter-thread synchronization issues regarding logging ourselves) is
 our conclusion, to which I'm not necessarily opposed if log4cplus
 itself can't solve it or we can find a better logging library that
 meets our requirement, then I'd suggest considering outsourcing the
 low level tasks as much as possible.  A major concern of mine for
 #2198 is that we are going to do too low-level things ourselves
 (handling flock(2) ourselves and now going to deal with pthread locks
 ourselves) while partially out-sourcing the feature (logging, in this
 case).

 I'd like to do either
 1. fully control everything ourselves, not just for synchronization
    issues but also the underlying logging itself, or
 2. out-source as many things that are not of our main concern as
    possible

 Option 1 is probably not realistic especially at this stage, so, in
 practice, what I'd suggest is to consider using a third party tool for
 the synchronization problems.  From a quick look
 boost::interprocess::named_mutex can be a candidate; it can be a
 unified synchronization mechanism for a multi-process and multi-thread
 environment.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2790#comment:9>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development