Service Virtualization

  • 1.  java.net.SocketException: Connection reset  error

    Posted Jul 10, 2018 02:42 AM

    Hi

    We have a Test suite comprising of 50+ cases. When we are running the cases individually we are getting the desired output but when we are staging the entire suite  we are facing below mentioned issues:

    1.Few of the test cases are throwing java.net.SocketException: Connection reset  error and hence getting aborted.

    2.The execution summary shows that all the test cases have been completed but in actual most of the test cases are not getting staged itself.

     

    For staging the suite we are following below procedure:

    1.Right click on the suite-->Select run Locally-->Click on stage button.

     

    PFB the error message for issue 1:

    java.net.SocketException: Connection reset ============================================================================ | Step: Add Payment ---------------------------------------------------------------------------- | Message: Connection reset ---------------------------------------------------------------------------- | Trapped Exception: Connection reset | Trapped Message: java.net.SocketException: Connection reset ---------------------------------------------------------------------------- STACK TRACE java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:209) at java.net.SocketInputStream.read(SocketInputStream.java:141) at com.itko.lisa.remote.client.socket.TrackingSocketInputStream.read(TrackingSocketInputStream.java:72) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930) at sun.security.ssl.AppInputStream.read(AppInputStream.java:105) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251) at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72) at com.itko.lisa.test.CommTrans.doSend(CommTrans.java:1074) at com.itko.lisa.test.CommTrans.send(CommTrans.java:843) at com.itko.lisa.test.CommTrans.sendPOST(CommTrans.java:803) at com.itko.lisa.ws.rest.RESTNode.doSend(RESTNode.java:226) at com.itko.lisa.ws.rest.RESTNode.doWebTrans(RESTNode.java:171) at com.itko.lisa.ws.rest.RESTNodeBase.execute(RESTNodeBase.java:380) at com.itko.lisa.test.TestNode.executeNode(TestNode.java:984) at com.itko.lisa.test.TestCase.execute(TestCase.java:1297) at com.itko.lisa.test.TestCase.execute(TestCase.java:1198) at com.itko.lisa.test.TestCase.executeNextNode(TestCase.java:1183) at com.itko.lisa.test.TestCase.executeTest(TestCase.java:1124) at com.itko.lisa.coordinator.Instance.run(Instance.java:208)



  • 2.  Re: java.net.SocketException: Connection reset  error

    Broadcom Employee
    Posted Jul 10, 2018 03:50 AM

    Hi Yugain,

     

    What version of DevTest are you testing this query?
    And could you please attach the workstation.log and the one of the test case which caused the error message in this question?
    If you cannot attach the files in this question for some reasons(public area or large volume of data), then could you open a support case and share the details?

     

    Thank you,



  • 3.  Re: java.net.SocketException: Connection reset  error

    Posted Jul 12, 2018 05:00 AM

    Hi Yusuke

     

    Thanks for your response.

     

    We are using Devtest version 10.2.1 and due to project constraints we can't attach files to the public forums.

    Can u please guide on how we can open a support case

     

    Thanks and Regards

    Yugain Sharna



  • 4.  Re: java.net.SocketException: Connection reset  error
    Best Answer

    Posted Jul 12, 2018 08:31 AM

    Please refer to Tech Tips: Opening a DevTest Support Case  

    When you say "When we are running the cases individually...getting the desired output..." do you mean that you are running the test case from within the DevTest Workstation or on the DevTest Server?  Is it possible that you have JKS files configured on one environment but not on the other (i.e., Workstation vs DevTest server) or one environment is using SSL and the other is not?   



  • 5.  Re: java.net.SocketException: Connection reset  error

    Broadcom Employee
    Posted Apr 26, 2019 05:07 AM

    HI Yugain

              I am currently working on a case from another customer with similar symptoms. Could you tell me if your problem still persists ?

     

    Thanks

    Sankar



  • 6.  RE: java.net.SocketException: Connection reset  error

    Posted Nov 22, 2019 08:10 AM

    Connection reset simply means that a TCP RST was received. This happens when your peer receives data that it can't process, and there can be various reasons for that. The simplest is when you close the socket, and then write more data on the output stream. By closing the socket, you told your peer that you are done talking, and it can forget about your connection. When you send more data on that stream anyway, the peer rejects it with an RST to let you know it isn't listening.