IZ29179: A CONNECTION PROBLEM WITH ONE OF THE CONNECTIONS PREVENTS THE OTHER CONNECTIONS FROM FUNCTIONING.

3.9.0.8-TIV-TEC-IF0103 IBM Tivoli Enterprise Console Version 3.9 Interim Fix

APAR status

• Closed as program error.

Error description

• Problem Description:
  A connection problem with one of the connections prevents the
  other connections from functioning.
  
  Failing TEC Component(s):       tec_gwr
  Customer/Recreate Environment:  AIX 5.3
  Database:                       N/A
  TME Framework:                  N/A
  Install Method:                 N/A
  TEC Server:                     TEC 3.9.0+FP07
  Tec Gateway:                    TEC 3.9.0+FP07
  Tec UI Server:                  TEC 3.9.0+FP07
  Websphere server:               N/A
  Tec Console:                    N/A
  Endpoints:                      N/A
  Adapter:                        N/A
  TMR/TEC same machine:           Yes
  Affected Locale(s):             N/A
  Collected Information :
  tec_ed
  tec_gateway
  tec_gwr.stdout  ; The output of the "tec_gwr -d -v ALL".
  .tec_gateway_diag_config
  tec_gateway.conf
  tec_gwr.diag
  tecad_win.conf
  (Placed in ECuRep - /ecurep/pmr/6/3/63942,999,760)
  
  Last Known Good Level:          N/A
  L3 Acknowledged:                Yes (LB)
  
  Recreate Steps/Correct information:   (Defect)
  <Recreate Environment>
  TEC server, TEC Gateway, Gateway Receiver:  AIX 5.3
  (192.168.112.10)
  Event Adapter:  WinXP (172.16.10.20)
                    and they have some another non-tme adapter
  host.
  
  <Recreate Steps>
  1. Stop the event adapter
  2. Disconnect the network cable from the WinXP box
  3. Restart the event adapter
  4. Generate 3,000 windows event.
     These events are cached on the adapter.
  5. Stop the event adapter
  6. Connect the network cable to the WinXP box
  
  7. Restart the event adapter
       start to send the cached event to the gateway receiver.
  8. continue to connect and to disconnect the network cable from
  the WinXP box every 2 or 3 seconds.
  
  9. following session remain wrongly as "ESTABLISHED" status.
  
  ----------------------------------------------------------------
       tcp4       0      0  192.168.112.10.5539
  172.16.10.20.3612
  ESTABLISHED
  
  ----------------------------------------------------------------
  
  10. gwr continue to receive the events from the other non-tme
  adapters.
      But they are not processed an these network session became
  the "CLOSE_WAIT" status.
  
  11. "ESTABLISHED" session which was described above 9, and many
  "CLOSE_WAIT" sessions are never released.
      We have to stop the gwr to release these network sessions.
      As a result, many events are lost.
  
  Local fix:
  none
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of tec_gwr non_tme event receiver
  ****************************************************************
  * PROBLEM DESCRIPTION: If a non tme EIF sender sends a fragment
  * of data to the tec_gwr receiver then is unable to send the
  * remainder, the tec_gwr will continue to wait for this data
  * until the tec_gwr process is terminated. While it is waiting
  * for this remaining fragment, no other connections are
  * processed, the failed connection remains in ESTABLISHED and
  * other connections may go into a CLOSED_WAIT state
  ****************************************************************
  * RECOMMENDATION: Apply maintenance vehicle listed below
  ****************************************************************
  The gateway receiver was blocking awaiting the data from the
  sender and so not servicing the other descriptors. The sender
  was unable to send any further packets so the receiver
  maintained its end in an ESTABLISHED state.
  

Problem conclusion

• Added a keyword (getmsg_timeout_seconds) that, when added to the
  tec_gateway.conf and set to a value > 0 and <=500 will then set
  the receiving socket to a non-blocking mode and timeout after
  the specified number of seconds. If this keyword is not present,
  set to zero, or a value out of range this timeout will be
  disabled and the old behavior will be used. If another packet
  arrives on that socket within the timeout, the timer will be
  reset. If no further fragment is received within that time, the
  socket is in error/closed, and processing of the remaining
  descriptors will take place. Note that the value of 500 seconds
  will exceed most normal network timeouts (but values so large
  are available for testing) and a value closer to 5 or 10 is
  recommended so as to be responsive to the remaining connections.
  Note also that decreasing the packet size (MaxPacketSize) will
  also reduce the chance of any fragmentation.
  
  The fix for this APAR is contained in the following
  maintenance packages:
  
  | LA Fix | 3.9.0.8-TIV-TEC-LA0096
  
  Note: Search IBM Technical Support web site for maintenance
  package availability.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  TIVOLI ENT.CONS

• Fixed component ID

  5698TEC00

Applicable component levels

• R390 PSY

     UP