getRpcReply Method Blocks Until Data is Available From Netconf Device

Open
#62 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
java
Domain
networking

Research direction

Start in src/main/java/net/juniper/netconf/NetconfSession.java at getRpcReply and inspect how the SSH channel input stream is read before the timeout check. Review the adapted test cases mentioned in the issue. Done means the method returns or times out when the device sends no data or stops between chunks, rather than blocking indefinitely.

Written by the indexing model from the issue text.

Description

This is my very first Github issue so bear with me if I missed any important ritual.

I noticed that when Netconf device does not respond to a RPC request, Netconf client hangs. I investigated the issue and found that it waits to read from channel input stream: https://github.com/Juniper/netconf-java/blob/c0fbedac484e11eb1a290ff9a86eb356c5e78236/src/main/java/net/juniper/netconf/NetconfSession.java#L139

There is a timeout check in getRpcReply method in NetconfSession class but it only kicks in when there is data to be read from SSH channel input stream. Thus, there are 3 main problematic scenarios:

  1. If Netconf device never sends data, getRpcReply hangs forever.
  2. If Netconf device sends data in multiple chunks and stops sending anything before timeout is reached, getRpcReply hangs forever (technically same with scenario 1)
  3. Timeout is actually determined by the sent data. Let's say timeout is 1000ms and Netconf device sends data in 2000ms. In that case getRpcReply wait for 2000ms. If data has the prompt chars, timeout does not occur, otherwise it occurs after 2000ms.

Main reason is, underlying input stream of SSH channel (PipedInputStream) provides blocking read. Therefore, it is better to check if there is data to be read before attempting read operation.

I have submitted regarding fix and adapted test cases accordingly. Tbh, I am not very proficient with streams and I may have analyzed the issue or implemented fix wrong. Please thread carefully :)

Dominant language
Java
Stars
90
Forks
64
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Juniper/netconf-java

All issues in Juniper/netconf-java

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.