1. Please help support our sponsors by considering their products and services.
    Our sponsors enable us to maintain high-speed Internet connection and fast webservers.
    They support this free information and knowledge exchange forum service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions

[DEFECT] SP 8.1.4 Server to Server Sessions

Discussion in 'TSM Server' started by ILCattivo, Jan 3, 2018.

  1. ILCattivo

    ILCattivo ADSM.ORG Senior Member

    Joined:
    Jul 9, 2013
    Messages:
    122
    Likes Received:
    5
    Location:
    Oxford, United Kingdom
    Happy New Year all.

    So I have 2 x SP 8.1.4 servers located at different DC locations. 1 x Windows 2016 & 1 x RHEL 7

    Both of these servers Protect each others Container Storage Pools via the Protect STG and Replicate Node cmds daily. Maxsessions=30 for the Storage Pool Protection process.

    Today I have discovered literally 100's of 'RecvW' SSL server sessions going back 200+ hours on one of the destination servers from the other source server? But not the other way round..?

    Admittedly the first Protect STG sync was a good 8+TB in size over the WAN link and took a few days to complete, but since then we have these orphaned RecvW' server sessions hanging around and they're simply not shifting once the protection of the storage pool is successful each day?

    Something I am missing here or potentially another bug?

    Thanks
     
  2.  
  3. ILCattivo

    ILCattivo ADSM.ORG Senior Member

    Joined:
    Jul 9, 2013
    Messages:
    122
    Likes Received:
    5
    Location:
    Oxford, United Kingdom
    I can confirm that having looked at an identical setup of mine with 2 x 8.1.0 SP Servers , both on win 2012, this behaviour is not present.!

    By the way, this odd orphaned session behaviour as described in the OP is Source [win2k16] > Destination [RHEL7] both SP 8.1.4
     
  4. marclant

    marclant ADSM.ORG Moderator

    Joined:
    Jun 16, 2006
    Messages:
    2,676
    Likes Received:
    374
    Occupation:
    Accelerated Value Specialist for Spectrum Protect
    Location:
    Canada
    RecvW (receive wait) is normally due to something at the networking layer. A transaction is in progress, but the receiving side suddenly has to wait mid-transfer. This situation "normally" stops when either the transmission continues or when the commtimeout is reached (60 seconds by default).
     
  5. ILCattivo

    ILCattivo ADSM.ORG Senior Member

    Joined:
    Jul 9, 2013
    Messages:
    122
    Likes Received:
    5
    Location:
    Oxford, United Kingdom
    Yep, can confirm that the COMMTIMEOUT setting is set to the default '60' so as you say, in theory the sessions should have stopped.

    Interestingly on my 8.1.0 setup the COMMTIMEOUT is a lot lot bigger.
     

Share This Page