Following on from the high level design, this page will provide a more detailed design approach to implement status update logging in the Java broker.
The logging hierarchy identified is not suitable to be directly used by Log4j as there is multiple routes and loops in the graph.
Abstracting the logging is recommended as this will allow us to simply provide Qpid specific optimisations such as providing the log prefix.
This design will cover the following areas:
At this stage configuration will be limited to the addition to the main config.xml file of the following option:
This status-update on setting will be the default value if the section is not included in the configuration file. The setting will be global for all virtualhosts and will be exposed via the management console as logger 'qpid.status' to allow dynamic setting.
The ability to configure more fine grained logging will be investigated here, but will not be implemented in the initial phase.
In the first phase updates only status updates will be provided. Status updates should take the form of general operational logging level, no logging on message delivery path way and No performance impact. The recommendation will be to have these enabled for production use.
e.g. Creation/Destruction events
The status updates can also be used in a second phase to provide additional logging to assist development.
The additional logging can be performed on the message delivery path way. This may have performance impact and so would not be recommended for long term production use.
e.g. Message Enqueue/Dequeue
The abstraction layer allows us to fully decouple the logging mechanism from any operational logging that the broker may wish to perform. The following code highlights show how we would abstract the logging operations.
The approach to logging is that a LogActor will be recoreded as a ThreadLocal and will be used to perform logging the log messages as highlighted on Logging Format Design. The LogActor will take two parameters, the LogSubject and the LogMessage. When a Status event occurs that should be logged the LogActor can be retrieved from the thread thus avoiding passing the LogActor through as a parameter to all locations were it must be logged. The initial LogActors will be AMQPActor and ManagementActor. Later phases would introduce HouseKeepingActor. These LogActors are responsible for checking that the logging should be performed for both themselves and the LogSubject. The LogActor then provids their log formatted name as per the format design along with the message to the RootMessageLogger. Initially the configuration will be a simple on/off, however, in a future phase the details can be used to identify if logging should proceed for that LogActor and LogSubject combination. At this stage selective configurations is not part of this design.
The use of the LogActor allows for situations such as Binding to have a Connection associated with the Binding. This will allow a Binding create event to be logged like this:
rather having no details about how the creation occurred:
Would result in the following based on the Logging Format Design.
Would result in the following:
Initial Status Messages