View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000280510000-004: ServicesSpecpublic2014-07-21 21:162014-11-18 18:55
ReporterMatthias Damm Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Target Version1.03Fixed in Version1.03 
Summary0002805: Handling for large HistoryRead requests
Description

How should a server behave if a client executes a HistoryRead Raw with a large number of nodes and the server is not able to process all nodes in the timeout set by the client.

Is the server allowed to return continuation points and empty value arrays for the remaining operations? Part 11 allows that only for Processed.
Should a server return BadTimeout for the remaining nodes?

What happens if the number of nodes exceeds the maximum number of continuation points? Browse defines Bad_NoContinuationPoints for this situation. This status code is not in the list for HistoryRead operation results.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0002887 closedRod Stein 10000-011: Historical Access Continuation point handling for large HistoryRead requests 
related to 0002892 closedMatthias Damm 10000-004: Services Allow Browse and Query to return continuation point and an empty result 

Activities

Karl Deiretsbacher

2014-07-29 16:44

developer   ~0005377

Meeting on July 29-2014:
We decided to allow returning continuation points with empty result list on all HistoryRead operations.
Also need to add Bad_NoContinuationPoints.

We also need to describe this in Part 11 - Matthias will create a proper mantis issue for Part 11.

Matthias Damm

2014-11-17 21:24

developer   ~0005615

Adds Bad_NoContinuationPoints to Table 54.
Adds following statement to description of 5.10.3 HistoryRead
In some cases it may take longer than the Client timeout hint to read the data for all nodes to read. Then the Server may return zero results with a continuation point for the affected nodes before the timeout expires. That allows the Server to resume the data aquisition on the next Client read call.

Jim Luth

2014-11-18 16:59

administrator   ~0005623

Reviewed and agreed to edited fix in 1.03.03

Issue History

Date Modified Username Field Change
2014-07-21 21:16 Matthias Damm New Issue
2014-07-29 16:44 Karl Deiretsbacher Note Added: 0005377
2014-07-29 16:44 Karl Deiretsbacher Status new => assigned
2014-07-29 16:44 Karl Deiretsbacher Assigned To => Matthias Damm
2014-11-17 21:24 Matthias Damm Category (No Category) => Spec
2014-11-17 21:24 Matthias Damm Note Added: 0005615
2014-11-17 21:24 Matthias Damm Status assigned => resolved
2014-11-17 21:24 Matthias Damm Resolution open => fixed
2014-11-17 21:31 Matthias Damm Relationship added related to 0002887
2014-11-18 16:59 Jim Luth Note Added: 0005623
2014-11-18 16:59 Jim Luth Status resolved => closed
2014-11-18 16:59 Jim Luth Fixed in Version => 1.03
2014-11-18 18:36 Jim Luth Relationship added related to 0002892
2014-11-18 18:55 Jim Luth Target Version => 1.03