Issues for Log Service v1.1 RTF

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5616: missing LogOffDuty exceptions
Issue 5617: Page 2-19. Description of write_recordlist
Issue 5618: 3. Appendix 1, page A-5 has missing definition of write_recordlist method
Issue 5627: Chapter 2.2.4.4, page 2-11
Issue 5628: Chapter 2.2.5.1, page 2-19
Issue 5629: Chapter 2.2.5.4, page 2-21
Issue 5630: Chapter 2.2.5.5, page 2-22. set_record_attribute operation
Issue 5631: Definition of DAG topology
Issue 5632: Chapter 2.2.7.1, page 2-24 copy and copy_with_id operations
Issue 5633: Chapter 2.2.7.2, page 2-25. destroy operation
Issue 5634: Chapter 2.3.1, page 2-26
Issue 5635: Chapter 2.4
Issue 5636: Chapter 2.4.1, page 2-29
Issue 5637: Chapter 2.5, page 2-33
Issue 8827: AttributeValueChange event section 1.4.4
Issue 8828: support QoS properties
Issue 8829: Section: 1.2.5.1
Issue 9259: Section: 1.2.4.11
Issue 9260: Section: 1.4.3
Issue 9261: Section: 1.4.3
Issue 9262: Section: 1.2.5.1
Issue 9311: Section: 1.2.5.1

Issue 5616: missing LogOffDuty exceptions (log-service-rtf)

1. Page 2-19 has missing LogOffDuty exception in the signatures of write_records and write_recordlist methods.


Currently there is:
void write_records(in Anys records)
        raises(LogFull, LogLocked, LogDisabled);
void write_recordlist(in RecordList list)
        raises(LogFull, LogLocked, LogDisabled);


Should be:
void write_records(in Anys records)
        raises(LogFull, LogOffDuty, LogLocked, LogDisabled);
void write_recordlist(in RecordList list)
        raises(LogFull, LogOffDuty, LogLocked, LogDisabled);

2. Page 2-19. Description of write_recordlist says "In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log." Why doesn't it say anything about attr_list field of RecordData struct? Seems to me that this field (list of name/value pairs) can also be modified and written to the log.

3. Appendix 1, page A-5 has missing definition of write_recordlist method in the Log interface and has doubled definition of write_records method.


All these issues are applied to version 1.0 as well (formal/2000-01-04).

·	Chapter 2.2.4.4, page 2-11. To have one style in the document and make it more readable I propose to change ulong to unsigned long.

·	Chapter 2.2.5.1, page 2-19. What are the values for minor codes: LOGFULL, LOGOFFDUTY, LOGLOCKED, and LOGDISABLED? Should those be defined in IDL?

·	Chapter 2.2.5.4, page 2-21. delete_records operation does not raise InvalidAttribute exception. This exception should be deleted from the description of the operation.

·	Chapter 2.2.5.5, page 2-22. set_record_attribute operation does not raise InvalidGrammar and InvalidConstraint exceptions. These exceptions should be deleted from the description of the operation

·	Chapter 2.2.6, page 2-24. It is not clear for reader what is DAG topology. I propose to explain this. At least write what it stands for, like "DAG (directed acyclic graph)".

·	Chapter 2.2.7.1, page 2-24. What is so resource consuming in the copy and copy_with_id operations? Why it can raise NoResources exception and any factory cannot? Factories also create logs and the log server also can have not enough resources to do it, but according to the specification factories do not raise NoResources exception. If NoResources should leave there then appendix 1 should be corrected since definitions of these copy operations do not contain NoResources exception in the list of raised exceptions and appendix 1 does not have definition of NoResources exception at all (should be put in DsLogAdmin module). Or if NoResources can be omitted then description of those copy operations should be modified

·	Chapter 2.2.7.2, page 2-25. destroy operation is not only inherited from CosEventChannelAdmin::EventChannel but also defined in BasicLog interface. It is worth to mention it, since destroy operation can also be invoked on BasicLog objects.

·	Chapter 2.3.1, page 2-26. It is more correct if it is said that BasicLogFactory creates BasicLog but not Log (similar to that EventLogFactory creates EventLog).

·	Chapter 2.4. Within the whole chapter in the description of every generated event "the log field" is used instead of "the logref field". Should be changed in every occurrence.

·	Chapter 2.4.1, page 2-29. Definition of the ObjectCreation struct contains logref field. This is different from the same definition in appendix 1 on page A-7. I think the correct version is on page 2-29. Then ObjectDeletion struct (page 2-30) does not have logref field. Is it OK? If yes, then "NOTE" in appendix 1 on page A-7 is wrong and not needed at all. If not, then the definition of that struct both on page 2-30 and in the appendix 1 should be modified.

·	Chapter 2.5, page 2-33. The paragraph of the second bullet point can also contain the TypedRecordIterator.

Section 1.4.4 states that the "AttributeValueChange event is generated by a log factor when one of its log changes one of changes one of the following attributes..." The description of the set_* methods state "An AttributeValueChange is generated whenever the * is set". The former implies that the event will be sent if the value is changed, the latter imples the event will be sent even if the value is the same.

I'm working on TAO's Log Service implementation, and I'm not sure how I'm supposed to support QoS properties. The spec for get_log_qos() method states it "returns a list of the quality of service properties supported by the log." This is different from the other get_* methods, which return the current value of the settings. If this is the intent, it should be emphasized, and perhaps a new method introduced to fetch the current QoS settings. The three defined QoS settings QoSNone, QoSFlush, and QoSReliability are mutually exclusive. But unlike the Notification Service Spec's section on QoS settings, there is no guideance wrt. semantics of a property list with multiple properties or what should be returned in the denied list in the UnsupportedQoS exception. 

I am in the process of updating TAO's Logging Service implementation. Section 1.2.5.1 stats "The Telecom Log Service proposes to define the following OMG Standard exception codes for use with the CosEvent and CosNotification push operations..." and goes on to mention a LOGFULL and LOGOFFDUTY minor code for the NO_RESOURCE [sic] SystemException, a LOGLOCKED minor code for the NO_PERMISSIONS SystemException, and a LOGDISABLED minor code for the TRANSIENT SystemException. TAO does not define these minor codes, so I checked the latest CORBA spec (3.0.3 / formal/04-03-12) and they are not in Appendix A either. What exactly does the spec mean "proposes to define" and what should an implementer do to handle these errors in the here and now.

The specification states "If the capacity of a log exeeds that of one of its log capacity alarm thresholds, ..." This wording is confusing: The log capacity (as set by set_max_size()) is not compared with the capacity alarm thresholds; it does not state that the ThresholdAlarm is sent once when the threshold has been met, which may lead some to believe the alarm events will be sent continuously; and the word "Exceed" means that a alarm would never be sent for a threshold of 100%. I think that something like "If after a log record has been written, the current size of a log, as expressed as a percentage of max log size, is greater or equal to the next log capacity threshold, then a ThresholdAlarm event is generated ..." might be clearer. 

The IDL for the ThresholdAlarm event defines three constants for the percieved_severity field: critical, minor, and cleared. The text says the "percieved_severity is minor if log is not full, and critical otherwise". If these are the only valid values, why is there a definition for cleared?

I am the current maintainer of the TAO logging service implementation. The specification is unclear what the interactions between set_max_size(), set_log_full_action(), and set_capacity_alarm_thresholds() have on the current processing of capacity alarms. For example, consider a log with DsLogAdmin::halt log full action and 0 (ie. infinate) max size, and a capacity alarm threshold list of [50, 75, 90, 100]. If the log has 80KB of records, and the max size is set to 100KB, are ThresholdAlarms supposed to be sent for crossing 50 and 75%, or should a threshold alarm only be sent once the log grows to 90%? Similar questions arise when the log full action is changed to/from DsLogAdmin::halt from/to DsLogAdmin::wrap, as the capacity alarm threshold processing changes from a percentage to a "gauge". Or when the capacity alarm threshold list is changed from one set of values to another.

The specification says that "The write_recordlist() operation is provided ass a convienience operation to allow the output of a query of one log to be written to another log. In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log.". This is the only place in the spec that RecordData is used, I believe that LogRecord was intended. Also, it is unclear whether the attr_list field should be copied. While it says "only the info field" is written, attr_list is among the fields listed that will be "assigned by the log". For what it's worth, the Orbix Log Service implementation appears to copy the attr_list. Their Enterprise Messaging Guide for ORBIX 6.2 says "write_recordlist() is functionally identical to write_records(). It writes data directly to the log and raises the same exceptions. The major difference is that the record's data is stored in a LogRecord. This allows you to add a series of name/value pair attributes to assist in querying the log". The TAO log service implementation, which I currently maintain, also copies the value of attr_list.

The specification says that "The write_recordlist() operation is provided ass a convienience operation to allow the output of a query of one log to be written to another log. In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log.". This is the only place in the spec that RecordData is used, I believe that LogRecord was intended. Also, it is unclear whether the attr_list field should be copied. While it says "only the info field" is written, attr_list is among the fields listed that will be "assigned by the log". For what it's worth, the Orbix Log Service implementation appears to copy the attr_list. Their Enterprise Messaging Guide for ORBIX 6.2 says "write_recordlist() is functionally identical to write_records(). It writes data directly to the log and raises the same exceptions. The major difference is that the record's data is stored in a LogRecord. This allows you to add a series of name/value pair attributes to assist in querying the log". The TAO log service implementation, which I currently maintain, also copies the value of attr_list.