View Issue Details

IDProjectCategoryView StatusLast Update
0004094Compliance Test Tool (CTT) Unified Architecture5 - General Problempublic2019-01-07 15:49
ReporterBernd Edlinger Assigned ToAlexander Allmendinger  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
PlatformPCOSWindowsOS Version8.1
Product Version1.03.340.378 
Target Version1.04 
Summary0004094: Base Information/Base Info Server Capabilities/*.js apparently fails to close sessions
Description

When I change the default behavior of our server to fail
new session requests if already too many sessions,

then it turns out that for instance:
Base Information/Base Info Server Capabilities/*.js fail to close
some sessions which was no problem when we had Re-use strategy.

Which make all following test cases fail.

TagsNo tags attached.
Files Affected

Activities

Paul Hunkar

2018-01-05 15:30

administrator   ~0008820

CMP Discussion;

This needs more information - which test scripts?

The CTT reuse its session - if the CTT did not activate it then the session should be reused by the server - so we are not understanding the problem.

Are you implying that a number of scripts do not close session that are complete?

Bernd Edlinger

2018-01-10 13:11

reporter   ~0008832

Yes, it happens for instance in
Base Info Server Capabilities/011.js MaxNodesPerWrite

There is a WriteRequest with 51 elements, which exceeds our array limit,
the server response is ERR BadEncodingLimitExceeded,
and the secure channel is closed by the stack,
but the session is still open, and now the CTT opens a new session.

And in Base Info Server Capabilities/015.js MaxNodesPerBrowse
just with a Browse Request.

At that point both sessions in the server are occupied,
and need to time out before they can be re-used.

Paul Hunkar

2019-01-05 17:42

administrator   ~0009793

All script should be reviewed to ensure they honor the limit reported by the server, i.e. we should not attempt to write more values then the array limit is set for in a single write.

If a secure channel is closed - but we did not close it or expect it to be closed - we should attempt to recover the session - we should also fail or generate a warning on the test that had the secure channel closure to ensure it is investigated (why did the channel close)

Issue History

Date Modified Username Field Change
2017-12-13 11:14 Bernd Edlinger New Issue
2018-01-05 15:30 Paul Hunkar Note Added: 0008820
2018-01-05 15:30 Paul Hunkar Assigned To => Paul Hunkar
2018-01-05 15:30 Paul Hunkar Status new => feedback
2018-01-10 13:11 Bernd Edlinger Note Added: 0008832
2018-01-10 13:11 Bernd Edlinger Status feedback => assigned
2019-01-05 17:42 Paul Hunkar Note Added: 0009793
2019-01-05 17:42 Paul Hunkar Assigned To Paul Hunkar => Alexander Allmendinger
2019-01-07 15:49 Paul Hunkar Target Version => 1.04
2019-01-28 14:14 Paul Hunkar Category General Problem => 4 - General Problem
2019-01-28 14:15 Paul Hunkar Category 4 - General Problem => 5 - General Problem