Issue 2348: DsLogNotification::ObjectDeletion in Telecom Log Service
Issue 2663: Adopt current OMG style of using CONST
Issue 2664: Change references to "LogFactory" to "BasicLogFactory"
Issue 2665: Argument in CapacityAlarmTresholdList tresholds doesn"t appear in IDL
Issue 2666: Clarify specification text in section 3.4 Log Generated Events
Issue 2667: Clarify text
Issue 2668: Text unclear to a log"s behavior when off_duty
Issue 2673: Typos in Log Service
Issue 2677: get_capacity_thresholdlist() and set_capacity_thresholdlist()
Issue 2678: slight conflict on pg 3-16
Issue 2679: "in Anys records" description on page 3-18 is unclear
Issue 2725: Clarification for untyped events
Issue 2726: The text for the copy() and copy_with_id() operations
Issue 2728: Specification inconsistent in generating AttributeValueChange events
Issue 2730: StateChange or a ProcessingErrorAlarm event not defined
Issue 2731: Clarification for proper value of AvailablityStatus
Issue 2753: Availability status under wrap condition
Issue 2754: Reset of Capacity Alarm Threshold under wrap condition
Issue 2755:
Issue 2756:
Issue 2757:
Issue 2758:
Issue 2759:
Issue 2762:
Issue 2763:
Issue 2764:
Issue 2768:
Issue 2771:
Issue 2773:
Issue 2774:
Issue 2777:
Issue 2920: Telecom logging -- illegal IDL
Issue 3120: Telecom Log Service issue
Issue 3458: Initial references?
Issue 3695: Viewing old logs
Issue 3752: bug in the Telecom Log Service IDL
Issue 4279: TelecomLogService/2000-01-04 -- typo
Issue 4799: OMG Document formal/01-04-08 --IDL issue
Issue 2348: DsLogNotification::ObjectDeletion in Telecom Log Service (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Documents: telecom/98-12-04 (text)
telecom/99-01-05 (IDL)
In module DsLogNotification, the event to be sent on log deletion is
defined as
struct ObjectDeletion {
Log logref;
LogId id;
TimeT time;
};
Here, "logref" is a reference to the Log object that has just been deleted,
and hence cannot be used for anything -- would it be better to abolish this
field? (Even though doing so would reduce the symmetry with ObjectCreation).
Resolution: Remove logref from the ObjectDeletion struct.
Revised Text: Specification Text
Section 3.4.2: ObjectDeletion Event
Modify by removing reference to logref.
This event is generated when a log is deleted.
struct ObjectDeletion {
LogId id;
TimeT time;
}
The ObjectDeletion struct defines the log deletion event.
The id field indicates the log identifier. The time field
indicates the time when the log was deleted.
Specification IDL
module DsLogNotification {
...
struct ObjectDeletion {
LogId id;
TimeT time;
};
...
};
Actions taken:
January 27, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2663: Adopt current OMG style of using CONST (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: there are a few enums defined in the
IDL. Perhaps it would be a good idea to adopt the
current OMG style of using CONST declarations for
these values as this allows easy extension of the values (which
enums do not). It is also nice to define the const types
as signed and to reserve all positive values for OMG
use and leave the negative values for vendors.
Resolution: The following are the enums defined in the Specification IDL and proposed changes:
Revised Text: 1. DsLogAdmin.idl: enum LogFullAction { wrap, halt };
The LogFullAction could probably be defined as CONST values, so vendors
or future extention can add more action items. InvalidLogFullAction exception
and LogFullActionType type are defined for LogFullAction.
module DsLogAdmin{
...
exception InvalidLogFullAction {};
typedef unsigned short LogFullActionType;
const LogFullActionType wrap = 0;
const LogFullActionType halt = 1;
...
};
Modify the operations on the Log and LogMgr interfaces that used
the old LogFullAction enum to use the new LogFullActionType
and to raise the appropriate exception:
module DsLogAdmin {
...
interface Log {
...
void set_log_full_action(in LogFullActionType action)
raises(InvalidLogFullAction);
...
};
interface LogMgr {
...
BasicLog create(in LogFullActionType full_action,
in unsigned long long max_size,
out LogId id)
raises(InvalidLogFullAction);
BasicLog create_with_id(in LogId id,
in LogFullActionType full_action,
in unsigned long long max_size)
raises(LogIdAlreadyExists, InvalidLogFullAction);
...
};
};
2. DsLogAdmin.idl: enum OperationalState { disabled, enabled };
This is left as is since the only possible values are 0 and 1.
3. DsLogAdmin.idl: enum AdministrativeState { locked, unlocked };
This is left as is since the only possible values are 0 and 1.
4. DsLogAdmin.idl: enum ForwardingState { on, off };
This is left as is since the only possible values are 0 and 1.
5. DsLogNotification.idl: enum PerceivedSeverity { critical, minor, cleared };
The PerceivedSeverity could be defined as CONST values for extention.
This is only used within the context of notifications and never supplied
as an argument to an operation. Therefore we only need to change it to a constant:
module DsLogNotification {
...
typedef unsigned short PerceivedSeverityType;
const PerceivedSeverityType critical = 0;
const PerceivedSeverityType minor = 1;
const PerceivedSeverityType cleared = 2;
struct ThresholdAlarm {
Log logref;
LogId id;
TimeT time;
Threshold crossed_value;
Threshold observed_value;
PerceivedSeverityType perceived_severity;
};
...
};
Revised Text:
Specification Text
Section 3.2.4.5: Log Full Action
Modify to use the LogFullActionType type and the InvalidLogFullAction exception.
Section 3.3.3: Log Creation
Modify to have create() and create_with_id() to use the LogFullActionType type and
the InvalidLogFullAction exception
Specification IDL
module DsLogAdmin{
...
exception InvalidLogFullAction {};
typedef unsigned short LogFullActionType;
const LogFullActionType wrap = 0;
const LogFullActionType halt = 1;
...
interface Log {
...
void set_log_full_action(in LogFullActionType action)
raises(InvalidLogFullAction);
...
};
interface LogMgr {
...
BasicLog create(in LogFullActionType full_action,
in unsigned long long max_size,
out LogId id)
raises(InvalidLogFullAction);
BasicLog create_with_id(in LogId id,
in LogFullActionType full_action,
in unsigned long long max_size)
raises(LogIdAlreadyExists, InvalidLogFullAction);
...
};
};
module DsLogNotification {
...
typedef unsigned short PerceivedSeverityType;
const PerceivedSeverityType critical = 0;
const PerceivedSeverityType minor = 1;
const PerceivedSeverityType cleared = 2;
struct ThresholdAlarm {
Log logref;
LogId id;
TimeT time;
Threshold crossed_value;
Threshold observed_value;
PerceivedSeverityType perceived_severity;
};
...
};
Actions taken:
Completed.
Actions taken:
May 27, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2664: Change references to "LogFactory" to "BasicLogFactory" (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: In the specification text, all references to "LogFactory" should be
changed to "BasicLogFactory" to match what is defined in
the specification IDL.
Resolution: completed, see revised text
Revised Text: All of the references to LogFactory interface will be changed to BasicLogFactory interface.
A distinction also needs to be made between the Log interface and the BasicLog interface.
Revised Text:
Specification Text
Figure 3-2: Log Inheritance
Include the BasicLog interface.
Table 3-1: Features of logs
Change "Log" to "BasicLog"
Section 3.3.1: Log Inheritance
Change to "There are five different log interfaces: BasicLog, EventLog, NotifyLog,
TypedEventLog, and TypedNotifyLog."
Figure 3-5: Factory Inheritance
Change "LogFactory" to "BasicLogFactory"
Specification IDL
No Changes
Actions taken:
Completed.
Actions taken:
May 27, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2665: Argument in CapacityAlarmTresholdList tresholds doesn"t appear in IDL (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: In the specification text, the BasicLogFactory::create() and
BasicLogFactory::create_with_id() operations have an extra
argument, in CapacityAlarmThresholdList thresholds, which does
not appear in the specification IDL. The reference to thresholds
in the specification text should be removed from the definitions
of BasicLogFactory::create() and BasicLogFactory::create_with_id().
The paragraphs in the specification text that describe the create()
and create_with_id() operations for the other log factories
(ie. EventLogFactory) should explain that they have an additional
argument, thresholds, besides the ones defined in the BasicLogFactory.
Resolution: resolved, see revised text
Revised Text: Resolution:
BasicLogs do not have a notion of thresholds and therefore the text needs to be changed.
The reference to thresholds in the specification text should be removed from the definitions
of BasicLogFactory::create() and BasicLogFactory::create_with_id(). The paragraphs in
the specification text that describe the create() and create_with_id() operations for
the other log factories should explain that they have an additional arguments and raise
addition exceptions besides the ones defined in the BasicLogFactory.
Revised Text:
Specification Text
Section 3.3.3: Log Creation
BasicLog create (
in LogFullActionType full_action,
in unsigned long max_size,
out LogId id
) raises (InvalidLogFullAction);
The create() operation in the BasicLogFactory interface allows clients to create new BasicLog objects.
The log full action and maximum size must be specified at creation time, but can be changed later.
The log id will be generated and returned as an out parameter. Exceptions are as follows:
An InvalidLogFullAction exception is raised if the full_action specified is not valid.
The create() operation in the EventLogFactory, NotifyLogFactory, TypedEventLogFactory and
TypedNotifyLogFactory interfaces creates new BasicLog, NotifyLog, TypedEventLog, and
TypedNotifyLog objects respectively. Each create() operation for the log factories takes arguments
and raises exceptions that are appropriate for the type of log being created.
BasicLog create_with_id (
in LogId id,
in LogFullActionType full_action,
in unsigned long max_size
) raises (LogIdAlreadyExists, InvalidLogFullAction);
The create_with_id() operation in the BasicLogFactory interface allows clients to create new BasicLog
objects specifying the id to be used. The log full action and maximum size must be specified at creation time,
but can be changed later. The log id is specified as an in parameter. Exceptions are as follows:
A LogIdAlreadyExists exception will be raised if this log id exists within the scope of the log factory.
An InvalidLogFullAction exception is raised if the full_action specified is not valid.
The create_with_id() operation in the EventLogFactory, NotifyLogFactory, TypedEventLogFactory,
and TypedNotifyLogFactory interfaces create new EventLog, NotifyLog, TypedEventLog, and
TypedNotifyLog objects respectively. Each create_with_id() operation for the log factories takes
arguments and raises exceptions that are appropriate for the type of log being created.
Specification IDL
Modify BasicLogFactory to raise correct exceptions:
module DsLogAdmin {
...
interface BasicLogFactory : LogMgr {
BasicLog create (
in LogFullActionType full_action,
in unsigned long long max_size,
out LogId id
) raises (InvalidLogFullAction);
BasicLog create_with_id (
in LogId id,
in LogFullActionType full_action,
in unsigned long long max_size,
) raises (LogIdAlreadyExists, InvalidLogFullAction);
};
};
Actions taken:
Completed.
Actions taken:
May 27, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2666: Clarify specification text in section 3.4 Log Generated Events (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The specification text is unclear and should make a note in
section "3.4 Log Generated Events" to explain that the manner
in which logs send log generated events to their corresponding
log factories is an implementation detail.
The idea is that applications (log/LogFactory clients) are only consumers
of log emitted events, they do not send events to the factory. Therefore, the
LogFactory does not need to expose the SupplierAdmin interface. How the log
actually forwards events to the factory is left up to the implementation -
use a SupplierAdmin object, or other means.
Resolution: resolved, see revised text below
Revised Text: Resolution:
The idea is that applications (log/LogFactory clients) are only consumers of log
emitted events, they do not send events to the factory. Therefore, the LogFactory
does not need to expose the SupplierAdmin interface. How the log actually forwards
events to the factory is left up to the implementation - use a SupplierAdmin object,
or other means.
Revised Text:
Specification Text
Section 3.4: Log Generated Events
NOTE: Log factories are responsible for the creation, deleation, management of logs,
as well as a supplier of events. A Log factory is not intended to be a consumer of events
and therefore does not expose a SupplierAdmin interface. It is left up to an implementation
detail as to how log generated events are passed from a log to it's log factory.
Specifcation IDL
No changes
Actions taken:
Completed.
Actions taken:
May 27, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2667: Clarify text (log_service-ftf)
Click here for this issue's archive.
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:
Issue 2668: Text unclear to a log"s behavior when off_duty (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The specification text is unclear to a log"s behavior when off_duty.
What should the log do when it"s not functioning due to being
outside the interval or shut down according to the weekmask? I assume it"s
still available for adjusting weekmask parameters, but does it just drop
log requests on the floor?
Resolution: rersolved, see revised text below
Revised Text: Resolution:
If a log is scheduled off-duty, then the log should respond to push with
a NO_RESOURCES system exception, with a minor code defined for scheduled
off duty.
To stay in line with Issue 2667 a new exception should be created, LogOffDuty,
which would be raised to the user if a write_records() or write_recordlist() operation
was invoked and the log was "off-duty".
Revised Text:
Specification Text
Section 3.2.5.1: Log Record Writing (Based on changes introduced in Issue 2667)
...
Some suggestions are to raise:
a NO_RESOURCE exception when the log is full
a NO_RESOURCE exception when the log is off duty
a NO_PERMISSIONS exception when the log is locked
a TRANSIENT exception the log is disabled
...
exception LogOffDuty {};
void write_records(in Anys records)
raises (LogFull, LogOffDuty, LogLocked, LogDisabled);
void write_recordlist(in RecordList list)
raises (LogFull, LogOffDuty, LogLocked, LogDisabled);
...
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 availability status is "off_duty", then a LogOffDuty exception is raised
and no log records are written.
If the log's administrative status 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 LogOffDuty {};
...
interface Log {
...
void write_records (in Anys records)
raises (LogFull, LogLocked, LogOffDuty);
void write_recordlist (in RecordList list)
raises (LogFull, LogLocked, LogOffDuty);
...
};
...
};
Actions taken:
Completed.
Actions taken:
May 27, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2673: Typos in Log Service (log_service-ftf)
Click here for this issue's archive.
Nature:
Severity:
Summary: There are various Typo's that need to be corrected:
Page 1-5 "Allows a log factory emits"
Page 1-5 "Allows multiple push or pull consumers can register"
Page 2-20 "An InvalidAttribute exception..." (delete_records does not raise Invalid exception)
Page 2-21 "interface Iterater"
Page 2-21 "When an invoking the get() operation..."
Page 2-22 "...initialized to the save values as the log..."
Page 2-26 "...TypedNotifyLogFactory interfaces create() new EventLog..." (no parens)
Resolution: Correct typos.
Revised Text: Revised Text:
Page 1-5: "Allows a log factory to emit ..."
Page 1-5: "Allows multiple push and pull consumers to register to receive log generated events ..."
Page 2-20: "An InvalidRecordId exception is raised ..."
Page 2-21: "interface Iterator"
Page 2-21: "When invoking the get() operation ..."
Page 2-22: "The copy() operation creates an empty log with its attributes initialized to the same
values as the log on which the operation was invoked."
Page 2-26: "... TypedNotifyLogFactory interfaces create new EventLog ..."
Actions taken:
Completed.
Actions taken:
May 28, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2677: get_capacity_thresholdlist() and set_capacity_thresholdlist() (log_service-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Summary: Should the Log interface define the get_capacity_thresholdlist()
and set_capacity_thresholdlist() operations? The BasicLog interface
inherits from Log and yet thresholds are meaningless in the context
of the BasicLog Why are they defined in Log and not in event and
notify log? And should BasicLog even bother checking the parameters or
doing anything?
Resolution: resolved , see text below
Revised Text: Resolution:
Capacity thresholds do have meaning for BasicLogs. What needs to be noted
is that instead of generating a ThresholdAlarm event, a BasicLog could write
to stderr or syslog when a capacity alarm threshold has been crossed.
Revised Text:
Specification Text
Section 3.2.4.11: Log Capacity Alarm Threshold
NOTE: BasicLogs are simple logs that are not aware of events nor are BasicLogFactorys
capable of generating events. Therefore an implementation needs to choose a different
technique to announce that a log is approaching full. Some example techniques are for
the BasicLog to write to stderr or syslog.
Specification IDL
No change
Actions taken:
Completed.
Actions taken:
June 1, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2678: slight conflict on pg 3-16 (log_service-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: Summary: There seems to be a slight conflict on pg 3-16: "New events delivered to a
halt log will simply be discarded, these events may still be forwarded if
the log forwarding state (described below) is on". How can events be
discarded _and_ forwarded?
Resolution: A log in the halt state only effect the logs ability to log new records.
Revised Text: Specificatin Text
Section 3.2.4.11: Log Capacity Alarm Threshold
New events delivered to a log in the "halt" state will not be logged, but the events may still
be forwarded if the log forwarding state (described below) is "on".
Specification IDL
No Change
Actions taken:
Completed.
Actions taken:
June 1, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2679: "in Anys records" description on page 3-18 is unclear (log_service-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: Summary: The description of the "in Anys records" parameter of the write_records()
operation on page 3-18 is unclear as to what the records should contain.
Resolution: The specification text should state that each Any contains the event to be logged.
Revised Text: Specification Text
Section 3.2.5.1: Log Record Writing
The write_records() operation takes a sequence of Anys as a prameter, each Any
containing the event to be logged.
Specification IDL
No Change
Actions taken:
Completed.
Actions taken:
June 1, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2725: Clarification for untyped events (log_service-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity:
Summary: A clarification needs to be made when untyped events are inserted and retrieved
from a typed log.
A client can use the standard "push" operation with a TypedProxyPushConsumer as
well as the type event operations defined on the interface generating the event.
What happens if a client invokes the typed_query() operation where some of the events
that pass the constraint were "push"ed as untyped events? Are those records ignored?
Are the type related fields of the TypedEventRecord left empty? Should we raise an exception?
Resolution: No action to be taken.
Revised Text: The behavior when untyped and typed events are stored in the same log is mostly
and implementation issue. How and if untyped events can be retrieved via
the typed_query() and typed_retrieve() operations should be left up to
the implementation.
Revised Text:
Specification Text
No Change
Specification IDL
No Change
Actions taken:
No action to be taken.
Actions taken:
June 13, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2726: The text for the copy() and copy_with_id() operations (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: The text for the copy() and copy_with_id() operations defined on the DsLogAdmin::Log
interface should specify that a DsLogNotification::ObjectCreation notification will
be generated as a result of the copy operation.
Resolution:
Revised Text: Log copies should be added to the description of when an ObjectCreation event
is generated.
Add a sentence should also be added to each operation that will generate an event
when invoked. This should include ObjectCreation, ObjectDeletion, ThresholdAlarm,
AttributeValueChange, and StateChange events.
Revised Text:
Specification Text
Section 3.2.4.2: Operation State
A StateChange event is generated whenever the operational state of a log changes.
Section 3.2.4.3: Administrative State
A StateChange event is generated whenever the administrative state of a log is set.
Section 3.2.4.4: Log Size
An AttributeValueChange event is generated whenever the size of a log is set.
Section 3.2.4.5: Log Full Action
An AttributeValueChange event is generated whenever the log full action of a log is set.
Section 3.2.4.6: Log Duration
An AttributeValueChange event is generated whenever the log duration interval of a log is set (either start or stop).
Section 3.2.4.7: Log Scheduling
An AttributeValueChange event is generated whenever the week mask of a log is set.
Section 3.2.4.11: Log Capacity Alarm Threshold
An AttributeValueChange event is generated whenever the capacity alarm threshold of a log is set.
Section 3.2.4.11: Log Capacity Alarm Threshold
Clients using a log that has a log full action of halt should register with the log factory
to receive the ThresholdAlarm event in order to be informed of a log full and halt conditions.
Section 3.2.4.12: Forwarding State
A StateChange event is generated whenever the forwarding state of a log is set.
Section 3.2.4.13: Log Filtering
An AttributeValueChange event is generated whenever the filter of a log is set.
Section 3.2.7.1: Copy Operations
An ObjectCreation event is generated whenever a log is copied.
Section 3.2.7.2: Destroy Operations
An ObjectDeletion event is generated whenever a log is destroyed.
Section 3.3.3: Log Creation
An ObjectCreation event is generated whenever a log is created.
Section 3.4.1: ObjectCreation Event
The ObjectCreation event is generated by a log factory after it creates a log or
one its logs is copied.
Specification IDL
No Change
Actions taken:
Completed.
Actions taken:
June 13, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2728: Specification inconsistent in generating AttributeValueChange events (log_service-ftf)
Click here for this issue's archive.
Nature:
Severity:
Summary: The specification is inconsisent in specifying which attributes generate
AttributeValueChange events. Currently AttributeValueChange events are
generated for:
capacityAlarmThreshold
logFullAction
maxLogSize
startTime
stopTime
weekMask
filter
An AttributeValueChange event should also be generated when the other
attributes of a log are changed:
administrativeState
maxRecordLife
qualityOfService
forwardingState
Resolution: resolved, see below
Revised Text: administrativeState and forwardingState have StateChange events generated when they change value.
Add a const AttributeType for maxRecordLife and qualityOfService.
Revised Text:
Specification Text
Section 3.2.4.9: Log Record Compaction
An AttributeValueChange event is generated whenever the max record life of a log is set.
Section 3.2.4.10: Quality Of Service
An AttributeValueChange event is generated whenever the quality of service of a log is set.
Section 3.4: Log Generated Events
AttributeValueChange: Generated when a log's attribute (capacity alarm threshold, log full action,
max log size, start time, stop time, week mask, filter, max record life, or quality of service)
is changed.
Section 3.4.4: AttributeValueChange Event
The AttributeValueChange event is generated by a log factory when one of its logs changes
one of the following attributes:
capacity alarm threshold
adding/removing/changing a constraint expression on the log's filter object
log full action
maximum log size
start time
stop time
week mask
max record life
quality of service
typedef unsigned long AttributeType;
const AttributeType capacityAlarmThreshold = 0;
const AttributeType logFullAction = 1;
const AttributeType maxLogSize = 2;
const AttributeType startTime = 3;
const AttributeType stopTime = 4;
const AttributeType weekMask = 5;
const AttributeType filter = 6;
const AttributeType maxRecordLife = 7;
const AttributeType qualityOfService = 8;
Specification IDL
module DsLogNotification {
...
typedef unsigned short AttributeType;
...
const AttributeType maxRecordLife = 7;
const AttributeType qualityOfService = 8;
...
};
Actions taken:
Completed.
Actions taken:
June 13, 1999: received issue
June 13, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2730: StateChange or a ProcessingErrorAlarm event not defined (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: The specification does not define a StateChange or a ProcessingErrorAlarm event
which are referenced in X.735 section 11.2.3, "Notifications".
Resolution: resolved, se revised text below
Revised Text: The StateChange event is defined. The ProcessingErrorAlarm event could be defined
to allow implemetations to generate event when a problem occurs within the log.
Clients could then register to receive this event and do the appropriate thing.
Revised Text:
Specification Text
No Change
Specification IDL
module DsLogNotification {
...
// The event generated by a log when a problem occurs within the log.
// The highest 20 bits of error_num are reserved for vendor
// specific Ids.
struct ProcessingErrorAlarm {
long error_num;
string error_string;
};
...
};
Actions taken:
Completed.
Actions taken:
June 13, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2731: Clarification for proper value of AvailablityStatus (log_service-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: would like to formally raise the following Issue for resolution
by the FTF (jointly with the ITU-T group responsible for X.735)
Location: section 2 : Log full action, page 2-12
The AB raised an issue regarding an ambiguity on the proper value for the
availability status. When the log is in the wrap condition. The FTF input text
added the following sentence:
Resolution: This is a duplicate of Issue 2753 -- closed
Revised Text:
Actions taken:
June 13, 1999: received issue
July 27, 1999: closed issue
Discussion:
Issue 2753: Availability status under wrap condition (log_service-ftf)
Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:
The AB raised an issue regarding an ambiguity on the proper value for the availability status, when the log is in the wrap condition. The FTF editor added the following sentence at the top of page 2-12 of to telecom/99-05-01, in an effort to clarify the AB issue: "When a log is full its availability status will change to indicate the log full condition. If a log's full action is set to 'wrap', it will never be in 'full' condition." This same ambiguity was discussed the ITU-T group which originally wrote the X.735 spec, and their proposed resolution has the opposite affect: Add the following explanation to the availability status value as a separate para after the text discussing wrap event behaviour : "The availability status indicates "logfull" when the capacity of the log is exceeded. In the case where halt behaviour is specified for the log the value implies no more records can be added. If wrap behaviour is specified, the value continues to remain as log full even though forthcoming records will be added by overwriting existing records. The wrap mode combined with logfull condition indicates that old records are lost as overwriting takes place. If records are deleted from the log, the logfull status value is removed from the availability status in either halt or wrap mode." The reason the ITU group has recommended "full" status is that it gives the information that records are being overwritten. When the log is full, records will be lost in response to forthcoming events. In Halt mode new records are not logged (i.e., lost), while in the wrap mode the oldest records are overwritten (i.e., lost). If a client comes and deletes records, then availabilitystatus can be reset. Otherwise one needs to have a different behaviour for halt and wrap in terms of the value for availability status.
Summary: This behaviour does not seem correct. Under a wrap condition, a capacity alarm gauge threshold should retrigger once in each period between wraps, but if the counter resets every time it crosses the thresold it will trigger more often. Thus the reset of the gauge , under wrap conditions, needs to be reworded as follows: " When a log object is created with the wrap option the capacity threshold alarms are triggered as if coupled to a gauge that counts from zero to the highest capacity of the log defined (reached each time the log wraps) and then resets to zero. If a log wraps, and no records are deleted to free space, capacity threshold events shall be emitted only when all the records in the log prior to the previous wrap occurance are completely overwritten. In other words, the gauge threshold is reset to zero each time the end of log marker is crossed by the addition of a new log record. For example if a log has a capacity of 2 Gigabytes a wrap event will occur only when every time 2 Gigabytes of data have been written to the log. "
The Notification Service defines:
module CosNotification {
// ...
interface QoSAdmin {
QoSProperties get_qos();
void set_qos(in QoSProperties qos)
raises(UnsupportedQoS);
// ...
};
// ...
};
module CosNotifyChannelAdmin {
// ...
interface EventChannel :
CosNotification::QoSAdmin,
CosNotification::AdminPropertiesAdmin,
CosEventChannelAdmin::EventChannel {
// ...
};
// ...
};
The Logging Service defines:
module DSLogAdmin {
// ...
interface Log {
// ...
QoSList get_qos();
void set_qos(in QoSList qos) raises(UnsupportedQoS);
// ...
};
};
module DsEventLogAdmin {
interface EventLog :
DsLogAdmin::Log,
CosEventChannelAdmin::EventChannel {};
// ...
};
module DsNotifyLogAdmin {
interface NotifyLog :
DsEventLogAdmin::EventLog,
CosNotifyChannelAdmin::EventChannel {
// ...
};
};
The net result is that DsNotifyLogAdmin::NotifyLog inherits get_qos()
and set_qos() twice, once from QoSNotification::QoSAdmin, and once from
DSLogAdmin::Log, which is illegal. This makes the Logging Service
unimplementable right now.
Looks like the operations in DSLogAdmin::Log will have to be renamed or
the inheritance structure will have to change.
This issue concerns the Telecom Log Service as described in the dtc/99-07-02 document. I think the following statements in the spec are not compatible together: "Log forwarding is determined solely by forwarding state, it is not affected by the log's administrative state, availability state, log duration, scheduling, or log full action." "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." If the log records are forwarded, then throwing system exceptions to the supplier doesn't make sense.
The Log Service spec doesn't state how a client gets access to the intial references for the service (namely, the various factories).
Assuming a log is persistent, how does one access the logged data after the system has been shut down? It seems important to be able to view this data after the system shuts down to determine if there were any glitches while the system ran or to troubleshoot any problems that occured.
I have just noticed a bug in the Telecom Log Service IDL. The "Log" interface defined in the "DsLogAdmin" module defines "set_qos" and "get_qos" operations. And, the DsNotifyLogAdmin::NotifyLog interface inherits both the DsLogAdmin::Log interface (indirectly, through inheritence of DsEventLogAdmin::EventLog) and the CosNotifyChannelAdmin::EventChannel interface. Note that the CosNotifyChannelAdmin::EventChannel interface inherits from CosNotification::QoSAdmin, which also defines "set_qos" and "get_qos" operations! This is invalid IDL inheritence as of CORBA 2.3! The same problem exists for the DsTypedNotifyLogAdmin::TypedNotifyLog interface. It indirectly inherits both DsLogAdmin::Log and CosNotification::QoSAdmin, and thus two versions of "set_qos" and "get_qos". There are a couple of possible solutions to this problem, but perhaps the easiest would be to simply rename the "set_qos" and "get_qos" operations defined in the Log interface as "set_log_qos" and "get_log_qos", respectively. If only there were an RTF that could do this... :-)
The issue is pretty simple and the easiest solution to resolve it is to rename the set/get_qos operations in the DsLogAdmin::Log by, respectively, set_log_qos and get_log_qos.
There is a typo on the first sentence on page 2-13. The words "enabled lock" should be "enabled log" in the following sentence : The stop field indicates the date and time at which an unlocked and enabled lock stops functioning.
I think the OMG Telecom Log Service IDL (DsLogAdmin and DsNotifyLogAdmin modules) isn't in accordance with the CORBA 2.6 "OMG IDL Syntax and Semantics" specification. Indeed the DsNotifyLogAdmin::NotifyLog interface inherits from both DsLogAdmin::Log.get_qos and CosNotification::QoSAdmin.get_qos operations, this is illegal according to section 3.7.5 (page 3-20) of the CORBA 2.6 specification. I've tried to compile the OMG Telecom Log Service with 2 differents ORBs (ORBacus 4.0.5 and JacORB 1.4beta2) without success.