ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005981 | Part 06: TTCN-3 Control Interface | Technical | public | 06-12-2011 14:36 | 20-12-2012 15:05

Reporter | Thilo Lauer |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | feature | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.3.1 (published 2011-06) |
Target Version | v4.5.1 (published 2013-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | 7.3.4.1.19, 7.3.4.1.20, 7.3.4.1.31, 7.3.4.1.32, 7.3.4.1.43, 7.3.4.1.44, 7.3.4.1.55, 7.3.4.1.56
Source (company - Author) | Devoteam Danet - Thilo Lauer

Summary | 0005981: TLI does currently not represent the p.check operation appropriately

Description

Currently there is no distinction in TLI between
p.receive(...) and p.check(receive(...))
p.getcall(...) and p.check(getcall(...))
p.getreply(...) and p.check(getreply(...))
p.catch(...) and p.check(catch(...))
For now these p.check(...) events have to be logged in TLI by:
tliMReceive_m/c,
tliPrGetCall_m/c,
tliPrGetReply_m/c,
tliPrCatch_m/c
but this does not indicate in the TLI-Log that the message itself remains in the port queue. This could be an important detail for interpreting the TLI-log.
For
MyPort.check;
MyPort.check(from MyPartner);
MyPort.check(-> sender MySenderVar);
any port.check;
a TLI log-mapping to e.g.:
tliMReceive_m/c,
would be very misleading in my opinion.
My suggested solution would be to define the TLI-functions below
tliMCheckReceive_m/c,
tliPrCheckGetCall_m/c,
tliPrCheckGetReply_m/c,
tliPrCheckCatch_m/c
completely identical to tliMReceive_m/c ... tliPrCatch_m/c except for the function's names.
[An alternative solution could be here to add a "check" flag as parameter to tliMReceive_m/c ... tliPrCatch_m/c as well as to the XML-representation of the logged event]
For
MyPort.check;
MyPort.check(from MyPartner);
MyPort.check(-> sender MySenderVar);
any port.check;
I would suggest to define a new TLI-function here, named e.g.:
tliCheck(...)
to indicate this event in the log.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006600 | closed | Ina Schieferdecker | Missing data in TLI check operations

Attached Files | CR5981_v1.docx (59,994) 14-12-2012 11:08 http://oldforge.etsi.org/mantis/file_download.php?file_id=2783&type=bug CR5981_v2.docx (81,665) 14-12-2012 13:39 http://oldforge.etsi.org/mantis/file_download.php?file_id=2785&type=bug CR5981_v3.docx (110,191) 20-12-2012 15:04 http://oldforge.etsi.org/mantis/file_download.php?file_id=2792&type=bug

Issue History
Date Modified | Username | Field | Change
06-12-2011 14:36 | Thilo Lauer | New Issue |
06-12-2011 14:36 | Thilo Lauer | Clause Reference(s) | => 7.3.4.1.19, 7.3.4.1.20, 7.3.4.1.31, 7.3.4.1.32, 7.3.4.1.43, 7.3.4.1.44, 7.3.4.1.55, 7.3.4.1.56
06-12-2011 14:36 | Thilo Lauer | Source (company - Author) | => Devoteam Danet - Thilo Lauer
10-07-2012 14:28 | Gyorgy Rethy | Note Added: 0010763 |
10-07-2012 14:28 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
10-07-2012 14:28 | Gyorgy Rethy | Status | new => assigned
10-07-2012 14:28 | Gyorgy Rethy | Target Version | => Edition 4.5.1
12-07-2012 15:41 | Ina Schieferdecker | Note Added: 0010888 |
10-08-2012 13:43 | Ina Schieferdecker | Note Added: 0011031 |
14-12-2012 11:08 | Ina Schieferdecker | Note Added: 0011271 |
14-12-2012 11:08 | Ina Schieferdecker | File Added: CR5981_v1.docx |
14-12-2012 11:08 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Tomas Urban
14-12-2012 13:39 | Tomas Urban | File Added: CR5981_v2.docx |
14-12-2012 13:43 | Tomas Urban | Note Added: 0011281 |
14-12-2012 13:44 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
20-12-2012 15:04 | Ina Schieferdecker | File Added: CR5981_v3.docx |
20-12-2012 15:04 | Ina Schieferdecker | Note Added: 0011301 |
20-12-2012 15:05 | Ina Schieferdecker | Status | assigned => closed
20-12-2012 15:05 | Ina Schieferdecker | Resolution | open => fixed
20-12-2012 15:05 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1
26-08-2013 13:30 | Jacob Wieland - Spirent | Relationship added | related to 0006600

Notes

(0010763)
Gyorgy Rethy
10-07-2012 14:28

STF discussion 2012-07-10: the issue exists, propose a solution.

(0010888)
Ina Schieferdecker
12-07-2012 15:41

The cleanest solution would be to define tliCheck that can take the logs of the different receiving operations. However, that would require to introduce a ReceivingOp Types for parameters to tliCheck. That is considered to be an overkill as basically all the structures in tliMCheckReceive_m/c, tliPrCheckGetCall_m/c, tliPrCheckGetReply_m/c, and tliPrCheckCatch_m/c would have to be repeated.
Another solution would be to add a check flag to all these operations. However, that would be a non-backward-compatible change to the interface.
There are two lightweight approaches:
1. define tliCheck just indicating a check operation that is to be followed ba a log of the log operation of the enclosed receiving operation (this is a work around for the new check logging operation proposal)
2. define the additional "am" parameter that is present in any logging operation to represent the check operation when loggin the enclosed receiving operation (this is a work around for the check tag proposal)
The issue needs to be discussed in the STF

(0011031)
Ina Schieferdecker
10-08-2012 13:43

Discussion in the STF: develop option 2

(0011271)
Ina Schieferdecker
14-12-2012 11:08

The proposal is defined as by reusing the Detected operations of TLI and defining 8 new operations for Checked: tliMChecked_m tliMChecked_c tliPrGetCallChecked_m tliPrGetCallChecked_c tliPrGetReplyChecked_m tliPrGetReplyChecked_c tliPrCatchChecked_m tliPrCatchChecked_c Please check

(0011281)
Tomas Urban
14-12-2012 13:43

I added four new operations: two of them for successful check any operations and two for logging mismatches in check any operations (in case addresses/components don't match). I also noticed the schema definitions in the Annex B don't contain the definitions from part 11.4.2.1, but that is probably intentional (so that there's no duplicated text in the draft)

(0011301)
Ina Schieferdecker
20-12-2012 15:04

Added the IDL definitions to Annex A in v3. Implemented v3.