<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic fin_wait_2 timeout in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/fin-wait-2-timeout/m-p/4588562#M532008</link>
    <description>Hi,&lt;BR /&gt;We have a whole bunch of Oracle forms creating socket comms to our HP-UX server in order to start server side C batch programs. We have experienced no problems until recently.&lt;BR /&gt;Occasionally (once in every 6 or so runs)one particular problematic form initiates the socket connection and starts up the C program on the server. But for 6 - 8 minutes or so appears to be doing no work and then suddenly returns the socket acknowledgement and then proceeds as usual.&lt;BR /&gt;To solve the problem (for a while) I set the fin_wait_2 timeout value from it's default value of 0 to 30000 ms and then after 30s I reset it back to 0. The result is that the number of sockets in fin_wait_2 state reduce from between 200 and 400 down to around 90 or so.&lt;BR /&gt;What is wrong in the environment that could cause this behavior? I am not sure whether I should permanently set the timeout value or is the problem in the form or C batch program?&lt;BR /&gt;No other forms/batches "appear" to be suffering from this problem.&lt;BR /&gt;&lt;BR /&gt;Any help would be appreciated.&lt;BR /&gt;Kind Regards&lt;BR /&gt;Graham</description>
    <pubDate>Mon, 22 Feb 2010 18:53:23 GMT</pubDate>
    <dc:creator>Graham Van der vaart_1</dc:creator>
    <dc:date>2010-02-22T18:53:23Z</dc:date>
    <item>
      <title>fin_wait_2 timeout</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/fin-wait-2-timeout/m-p/4588562#M532008</link>
      <description>Hi,&lt;BR /&gt;We have a whole bunch of Oracle forms creating socket comms to our HP-UX server in order to start server side C batch programs. We have experienced no problems until recently.&lt;BR /&gt;Occasionally (once in every 6 or so runs)one particular problematic form initiates the socket connection and starts up the C program on the server. But for 6 - 8 minutes or so appears to be doing no work and then suddenly returns the socket acknowledgement and then proceeds as usual.&lt;BR /&gt;To solve the problem (for a while) I set the fin_wait_2 timeout value from it's default value of 0 to 30000 ms and then after 30s I reset it back to 0. The result is that the number of sockets in fin_wait_2 state reduce from between 200 and 400 down to around 90 or so.&lt;BR /&gt;What is wrong in the environment that could cause this behavior? I am not sure whether I should permanently set the timeout value or is the problem in the form or C batch program?&lt;BR /&gt;No other forms/batches "appear" to be suffering from this problem.&lt;BR /&gt;&lt;BR /&gt;Any help would be appreciated.&lt;BR /&gt;Kind Regards&lt;BR /&gt;Graham</description>
      <pubDate>Mon, 22 Feb 2010 18:53:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/fin-wait-2-timeout/m-p/4588562#M532008</guid>
      <dc:creator>Graham Van der vaart_1</dc:creator>
      <dc:date>2010-02-22T18:53:23Z</dc:date>
    </item>
    <item>
      <title>Re: fin_wait_2 timeout</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/fin-wait-2-timeout/m-p/4588563#M532009</link>
      <description>Shalom Graham,&lt;BR /&gt;&lt;BR /&gt;I would look into how this form is coded first. If there was a general problem with Oracle forms, there would be consistent behavior with other forms.&lt;BR /&gt;&lt;BR /&gt;I do not believe that chancing the network configuration is a good answer here.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Mon, 22 Feb 2010 19:27:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/fin-wait-2-timeout/m-p/4588563#M532009</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2010-02-22T19:27:50Z</dc:date>
    </item>
  </channel>
</rss>

