View Issue Details

IDProjectCategoryView StatusLast Update
000232310000-005: Information ModelSpecpublic2017-05-23 15:59
ReporterNathan PocockAssigned Tojeffhardingabb  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0002323: Clarification of ServerShutdown definition and behavior required
Description

The definition of ServerState.SHUTDOWN_4 is described as follows:<br>
<br>
"The server has shut down or is in the process of shutting down. Depending on the implementation, this might or might not be visible to clients."<br>
<br>

Both sentences above are too vague. For example:<br>
Sentence #1: <br>

  • the "server" refers to what? an internal component, the server process, or application?<br>
  • the "has" word, how can that be?<br>
  • the "process" of shutting down also requires clarification.
    Sentence #2<br>
  • what EXACTLY "might or might not" be visible to clients?<br>
  • a description as to WHY the above condition exists should be provided (cmpwg knows why, i.e. timing; but its not obvious)<br>
    <br>

Additionally, Table 142 – ServerStatusDataType Structure describes the fields within the structure; unfortunately the SHUTDOWN_4 definition describes a "shutdown" by refering to it in the description thereby defeating the definition. Also, there's no documentation that we can find that describes HOW to use this structure. The testing that's currently defined for this behavior was ported from the COM tests (IOPCShutdown).<br>
<br>
Since no behavior is described for the shutdown procedure a vendor simply decided that there was no value in using this structure, even though its in his address space and clients subscribe to it, and therefore simply immediately closes his application thereby providing no notification to attached clients. His logic is sound, based on the specs. His logic: I'll set SecondsTillShutdown=0 and then shutdown; Clients must be able to handle a lost connection and enter a cycle of re-connecting.<br>
<br>
So we need more clarification on the intended usage (to avoid any specifics, if preferred) to be defined for both the Server and Client. The level of detail might also include the accessibility of UA Services, e.g. when the server enters into shutdown mode ONLY the services that free-up resources would be allowed, i.e. DeleteSub, DeleteMonitored..., CloseSess... etc.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0002620 closedMatthias Damm 10000-004: Services Special notification message type for system information 

Activities

Jim Luth

2013-01-22 19:59

administrator   ~0004432

We discussed this with Nathan in the telecon today, but he dropped off and we didn't come to closure.

ServerState.SHUTDOWN_4 and some other states are there for those servers that choose to do an orderly shutdown and notify clients for a period of time before completely shutting down. Orderly shutdown was a mandated behavior for OPC DA, but for UA we designed robustness into the abrupt (disorderly?) shutdown so we decided there was little value in making an orderly shutdown mandatory.

The statement in the spec: “Depending on the implementation, this might or might not be visible to clients." should be clarified with additional text to explain that if a server does not do an orderly shutdown, the ServerState.SHUTDOWN_4 need not be written since no one will ever be able to read it. If the server does do an orderly shutdown then the ServerState SHOULD be updated as described.

Jim Luth

2013-02-05 17:58

administrator   ~0004460

Also review the text in Part 4 6.5 for consistency.

Jim Luth

2013-08-06 17:53

administrator   ~0004909

Discussed in telecon and agreed to move this issue to Part 4 since such behavior needs to be defined with the service in Part 4, not with the datatype in Part 5.

Nathan Pocock

2015-08-06 18:07

viewer   ~0006295

CMPWG Aug-6-2015:

While discussing Client behavior test-cases for Redundancy the topic of SecondsTillShutdown came up. We did a search through the specs thinking this issue was resolved (we couldn't remember for sure) and found that more commentary is needed in the spec.

We couldn't determine the right spec. Part 4 does not cover much information; Part 3 has none; Part 5 seems to have the most.

Some text considerations could include:

  • servers should determine if clients are connected and then adjust accordingly
  • no clients connected can result in an immediate shutdown
  • clients connected should incur a delay detectable in SecondsTillShutdown

Jim Luth

2017-05-16 22:35

administrator   ~0008102

Jeff to integrate changes proposed by Matthias.

jeffhardingabb

2017-05-16 22:54

developer   ~0008103

Added Clarification to Table 135 and Table 143.

Jim Luth

2017-05-23 15:59

administrator   ~0008160

Agreed to changes edited in telecon.

Issue History

Date Modified Username Field Change
2013-01-18 14:33 Nathan Pocock New Issue
2013-01-22 19:59 Jim Luth Note Added: 0004432
2013-01-22 20:00 Jim Luth Status new => assigned
2013-01-22 20:00 Jim Luth Assigned To => Wolfgang Mahnke
2013-02-05 17:58 Jim Luth Note Added: 0004460
2013-08-06 17:51 Jim Luth Project 10000-005: Information Model => 10000-004: Services
2013-08-06 17:52 Jim Luth Assigned To Wolfgang Mahnke => Matthias Damm
2013-08-06 17:53 Jim Luth Note Added: 0004909
2014-12-16 13:19 Matthias Damm Relationship added related to 0002620
2015-01-15 23:25 Matthias Damm Category (No Category) => Spec
2015-01-15 23:25 Matthias Damm Description Updated
2015-01-15 23:26 Matthias Damm Description Updated
2015-01-15 23:39 Matthias Damm Target Version => 1.04
2015-08-06 18:07 Nathan Pocock Note Added: 0006295
2017-05-16 22:34 Jim Luth Project 10000-004: Services => 10000-005: Information Model
2017-05-16 22:34 Jim Luth Assigned To Matthias Damm => jeffhardingabb
2017-05-16 22:35 Jim Luth Note Added: 0008102
2017-05-16 22:54 jeffhardingabb Note Added: 0008103
2017-05-16 22:54 jeffhardingabb Status assigned => resolved
2017-05-16 22:54 jeffhardingabb Fixed in Version => 1.04
2017-05-16 22:54 jeffhardingabb Resolution open => fixed
2017-05-23 15:59 Jim Luth Note Added: 0008160
2017-05-23 15:59 Jim Luth Status resolved => closed