Issue 2667: Clarify text (log_service-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The specification text is unclear to a log"s behavior when disabled. If the log is disabled ("due to some run time catastrophy"), how should the log respond to requests? Since it is active enough to respond to "get_operational_state ()" requests, shouldn"t it throw exceptions? Is it allowed to drop log requests on the floor in that case? It could throw a LogLocked exception, but in that case, should the log lock when it enters the disabled state? Resolution: resolved, see revised text Revised Text: Resolution: A new exception, LogDisabled, should be defined and raised by write_records() and write_recordlist() when the log is in the disabled state. Guidelines should be given to suggest which SystemException to raise when each of the states that prevent a log record creation exist (NO_RESOUCE for log full, NO_PERMISSIONS for log locked, TRANSIENT for log disabled). Revised Text: Specification Text Section 3.2.5.1: Log Record Writing Log records are written to a log as follows: 1. Via the push/pull operationds defined on Event Channel or Notification Channel Since a log "is-a" EventChannel, NotificationChannel, TypedEventChannel, or TypeNotificationChannel log records are written to the log by event suppliers using either the push or pull method. The event suppliers connect themselves to a proxy consumer located within the log. A log may be not be able to create any new log records because it is full, locked, or disabled. If a log cannot create new log records when a push operation is invoked, then the push operation should fail and a SystemException should be raised. The Telecom Log Service proposes to define the following OMG Standard Minor exception codes for use with the CosEventService and CosNotificationService push operations: LOGFULL minor code When a push operation is invoked and a log is full, then a NO_RESOURCE SystemException is raised with a LOGFULL minor code. LOGOFFDUTY minor code When a push operation is invoked on a log that is off-duty, then a NO_RESOURCE SystemException is raised with a LOGOFFDUTY minor code. LOGLOCKED minor code When a push operation is invoked on a log that is locked, then a NO_PERMISSIONS SystemException is raised with a LOGLOCKED minor code. LOGDISABLED minor code When a push operation is invoked on a log that is disabled, then a TRANSIENT SystemException is raised with a LOGDISABLED minor code.locked, or disabled. 2. via the write_records() and write_recordlist() operations defined on Log exception LogFull {short n_records_written}; exception LogLocked {}; exception LogDisabled {}; void write_records(in Anys records) raises (LogFull, LogLocked, LogDisabled); void write_recordlist(in RecordList list) raises (LogFull, LogLocked, LogDisabled); Lightweight log clients or legacy applications that are "event unaware" can use the write operations defined on the Log interface. The log record is written directly to the log and is not subject to the log filter and also will not be forwarded. The write_records() operation takes a sequence of Anys as a parameter, each Any containing a log record to be logged. The write_recordlist() operation is provided as a convenience operation to allow the output of a query of one log to be written to another log. In this case, only the "info" filed (event content) of the RecordData struct is written to the log. The LogRecord id and logging time will be assigned by the log. Both the write_records() and write_recordlist() operations have the following behavior: If the log's availability status is "log_full" and its LogFullAction is "halt", then a LogFull exception is raised and the number of log records written will be returned in the exception. If the log's administrative state is "locked", then a LogLocked exception is raised and no log records are written. the log's operational state is "disabled", then a LogDisabled exception is raised and no log records are written. Specification IDL module DsLogAdmin { ... exception LogDisabled {}; ... interface Log { ... void write_records (in Anys records) raises (LogFull, LogLocked, LogDisabled); void write_recordlist (in RecordList list) raises (LogFull, LogLocked, LogDisabled); ... }; ... }; Actions taken: Completed. Actions taken: May 27, 1999: received issue July 27, 1999: closed issue Discussion: End of Annotations:===== Sender: spruce@ovdm40.cnd.hp.com Message-ID: <374B4B01.94936F4B@fc.hp.com> Date: Tue, 25 May 1999 19:14:41 -0600 From: Stephen Spruce Organization: Telecom Management Division X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/777) MIME-Version: 1.0 To: juergen@omg.org Subject: Issues for Telecom Log Service Content-Type: multipart/mixed; boundary="------------5359345BE554D3D338D5D19C" X-UIDL: 30aaae3f45cba14fe2a8031cca11ac75 Hi Juergen, Attached is a list of issues that have been brought up against the Telecom Log Service (TLS) since it reached the Adopted Specification stage. I am not exactly clear on the content that is necessary for these issues, so let me know if you need more information about any or all of them. ISSUE ----- (from Matt Braun: mjb2@cs.wustl.edu) The specification text is unclear to a log's behavior when disabled. If the log is disabled ("due to some run time catastrophy"), how should the log respond to requests? Since it is active enough to respond to "get_operational_state ()" requests, shouldn't it throw exceptions? Is it allowed to drop log requests on the floor in that case? It could throw a LogLocked exception, but in that case, should the log lock when it enters the disabled state?