[NETCONF-155] RestPerfClient: Hang on java.util.concurrent.CancellationException. Created: 24/Feb/16  Updated: 15/Mar/19  Resolved: 01/Apr/16

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Jozef Behran Assignee: Jakub Morvay
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 5413

 Description   

When RestPerfClient encounters java.util.concurrent.CancellationException, it fails to exit after the request sending is completed, causing the test run to either hang indefinitely or fail due to a timeout (and scrapping logs from the test run).



 Comments   
Comment by Jozef Behran [ 29/Feb/16 ]

One more piece of information that might be important: The java.util.concurrent.CancellationException occurs in the thread "main" and there is/are another thread(s) running (I see "pool-4-thread-1", the numbers may differ in your case).

Comment by Jakub Morvay [ 09/Mar/16 ]

https://git.opendaylight.org/gerrit/#/c/35973/

Comment by Jozef Behran [ 21/Mar/16 ]

The change was merged and this test run shows it fixed the problem:

https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-1node-periodic-scale-only-beryllium/115/

(look into restperfclient-netconf-scale-txt-Mdsal-netconf-connector.log).

This bug can be closed.

Comment by Jozef Behran [ 21/Mar/16 ]

Ok, after more thorough investigation I realized that the run actually shows that the RestPerfClient appear to be still hanging on that exception. The change is that once the peer is deconfigured, the RestPerfClient gets out of the loop and terminates, reporting the exception.

Comment by Jakub Morvay [ 21/Mar/16 ]

The change has not been merged to Beryllium yet.

https://git.opendaylight.org/gerrit/#/c/35980/3

Comment by Jakub Morvay [ 23/Mar/16 ]

Lithium:

https://git.opendaylight.org/gerrit/#/c/36594/

Generated at Wed Feb 07 20:14:18 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.