8 Replies Latest reply: Dec 19, 2006 12:34 AM by 807581 RSS

    Re: iPlanet Application server 6.5 connection timeout

    807581
      Dear all,
      Now I'm facing the problem about the connection lost between iPlanet application server 6.5 and iWS 6.0. I've developed a online banking web application and execute under IAS6.5. All necessary patches were installed. After the system run 5-8 days, the connection lost between app and web server would be happened and as the result user experieneced page not displayed. After investigate from server log , the application server log seems no particular error was found. After connection lost, no request from web server therefore no messages logged inside.
      In the meantime investigate from webserver, found the connection lost inside the error log file. The following error was trigger from the error log file:
      [24/Oct/2005:09:42:57] info ( 1709): conn reports: socket receive error (RecvBuffer 1) (conn 0xf52b60, sock 127, host 0xc009cfd1, port 10818)
      [24/Oct/2005:09:42:57] info ( 1709): GXConnMgr reports: Closing conn f52b60
      [24/Oct/2005:09:42:57] info ( 1709): GXConnMgr reports: Delete conn table
      [24/Oct/2005:09:42:57] info ( 1709): RunConnection reports: Close conn=0xf52b60
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): conn reports: new connection (conn 0x1006140, sock 128, host 0xc009cfd1, port 10818)
      [24/Oct/2005:09:42:57] info ( 1709): MakeNewConn reports: Made new connection 0x1006140 to host (0xc009cfd1 10818)
      [24/Oct/2005:09:42:57] info ( 1709): GXConnMgr reports: Closing conn 1006140
      [24/Oct/2005:09:42:57] info ( 1709): GXConnMgr reports: Delete conn table
      [24/Oct/2005:09:42:57] info ( 1709): conn reports: new connection (conn 0xfea2c8, sock 164, host 0xc009cfd1, port 10818)
      [24/Oct/2005:09:42:57] info ( 1709): MakeNewConn reports: Made new connection 0xfea2c8 to host (0xc009cfd1 10818)
      [24/Oct/2005:09:42:57] info ( 1709): GXConnMgr reports: Closing conn fea2c8
      [24/Oct/2005:09:42:57] info ( 1709): GXConnMgr reports: Delete conn table
      [24/Oct/2005:09:42:57] info ( 1709): GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xfea2c8, sock 0, host 0x0, port 0)
      [24/Oct/2005:09:42:57] info ( 1709): conn reports: new connection (conn 0xfb8d28, sock 164, host 0xc009cfd1, port 10818)
      [24/Oct/2005:09:42:57] info ( 1709): MakeNewConn reports: Made new connection 0xfb8d28 to host (0xc009cfd1 10818)
      [24/Oct/2005:09:44:17] info ( 1709): conn reports: socket receive error (RecvBuffer 1) (conn 0xfb8d28, sock 164, host 0xc009cfd1, port 10818)
      [24/Oct/2005:09:44:17] info ( 1709): GXConnMgr reports: Closing conn fb8d28
      [24/Oct/2005:09:44:17] info ( 1709): GXConnMgr reports: Delete conn table
      [24/Oct/2005:09:44:17] info ( 1709): RunConnection reports: Close conn=0xfb8d28
      This error keep to raise until restart the application server. This kind of the problem was happened 3 times and the time was happened very closed. I suspect it is related to high volume network traffic to conflict the web connection and make it down. Any idea to resolve this problem ? Could I apply some changes inside the registry such as increase the value of connection time out or whatelse ? Thank you for anyone concern my problem.

      Ricky
        • 1. Re: iPlanet Application server 6.5 connection timeout
          807581
          Hi,
          I am also facing same problem about the connection lost between iPlanet application server 6.5 and iWS 6.0.
          GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0xf52b60, sock 0, host 0x0, port 0)
          Why it is happening after sevendays running successfully
          Any body help on this please
          • 2. Re: iPlanet Application server 6.5 connection timeout
            807581
            You can try increasing KeepAliveTimeOut (seconds) in the registry:
            "Application Server\6.5\CCSO\HTTPAPI"
            • 3. Re: iPlanet Application server 6.5 connection timeout
              807581
              thanks for update.

              Your solution is valuable

              Please Can u give the exact reason for what causes this error ??

              GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0x17cd368, sock 0, host 0x0, port 0)

              Thanks for quick update.
              • 4. Re: iPlanet Application server 6.5 connection timeout
                807581
                GXConn::GetNextBuffer() reports: invalid reply type received in GetNextBuffer (conn 0x17cd368, sock 0, host 0x0, port 0) message is the follow up of the lost connection between web server plugin and KXS engine.
                It doesn't make much sense for the end user, please see more info here:
                http://docs.sun.com/source/819-2020/rn_65SP1_mu7_sol.html
                (search for Firewall Time-outs).
                • 5. Re: iPlanet Application server 6.5 connection timeout
                  807581
                  Thanks for your update.

                  You mean firewall time-outs can make the disconnectivity between iWS & iAS, also wanted to know if there could be a dependency on OS(solaris) level tcp_time_wait_interval setting.

                  Can you plz. throw your views on this regard.

                  After a connection has been closed by both the client and the server, the port remains unavailable for a certain amount of time, so that a new program does not inadvertently get packets that were intended for the old program. On Solaris machines, the default value of tcp_time_wait_interval is 240,000 ms (4 minutes). It is recommended that this be set at 60000 ms (1 minute) or even at 30000 (30 seconds) for better performance in socket communication intensive programs. The value can be modified and examined on a running system.

                  /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000

                  /usr/sbin/ndd -get /dev/tcp tcp_time_wait_interval

                  reference url: http://docs.sun.com/source/816-5794-10/os_tune.htm#996742
                  • 6. Re: iPlanet Application server 6.5 connection timeout
                    807581
                    Yes, firewalls(at least some of them) could make appserver loose connection to the webserver. Regardless of firewall values increasing KeepAliveTimeOut is a good thing.
                    Speaking of tcp_time_wait_interval change, it is actually a performance tuning change relevant to faster response time of the apps deployed on your appserver. I don't believe changing this parameter could help you sort out your current issue.
                    • 7. Re: iPlanet Application server 6.5 connection timeout
                      807581
                      Hmm, we are getting the same messages, but looking at the
                      timeout it is set to 3600 (seconds), which seems absurdly
                      high on a DMZ firewall. What would be a reasonable value to
                      set this to?
                      • 8. Re: iPlanet Application server 6.5 connection timeout
                        807581
                        Or would this value be milliseconds? We are running iAS6.5SP1MU7, but
                        apparently the unit for this value has changed over the last few versions. (or
                        only in the documentation?) I think 1 hour for a timeout is very long, but 3.6
                        seconds could be too short (is for instance a gc is running or the appserver
                        is busy).

                        From http://docs.sun.com/source/816-6436-10/rn_65_mp3_sol.html:
                        Enter the value for this key in milliseconds, which could be equal to
                         the default TCP/IP timeout value of the firewall, or equal to the number of 
                        milliseconds for the firewall to timeout.
                        From http://docs.sun.com/source/819-2020/rn_65SP1_mu7_sol.html:
                        Enter the value for the key, KeepAliveTimeOut (in seconds), which 
                        could be equal to the default TCP/IP timeout value of the firewall, or equal to 
                        the number of seconds for the firewall to timeout.
                        Also, if I read the description of the attribute, then it is more like an interval
                        than a timeout. Intervals need to be decreased in order to prevent connection
                        loss, but timeouts need to be increased to accomplish the same. Now
                        which is it ;-).
                        This value represents the number of seconds the plugin will wait for 
                        inactivity after the first request, and keep sending messages at the 
                        KeepAliveTimeOut interval to keep the connection between the web server 
                        plugin and KXS process of the application server alive.
                        Any ideas?

                        Best regards, Robert