locked
Issue with DSS TCP Transport Service RRS feed

  • Question

  • I have encountered a serious dss issue that I need to resolve asap.

                    We are using DSS & CCR on multiple computers on a network

                    Our server is running a DSS Host with a 'DSS Server Service'

                    Multiple clients running on different machines are running DSS Host with DSS Client Services

                    The DSS Client Services Query the 'DSS Server Service'

                    So far so good everything works fine.

                However when we have been cycling clients (DSS Host – not just the DSS service)  to shutdown and re-start every 90 seconds to test certain auto-update scenarios, we have found that when we cycle 4 or more clients our servers' CPU pegs at 100% as the clients disconnect.  The CPU on the server never recovers.  I have a profiler screen shot here (http://www.uscg.org/Profiler%20Screenshot.png) that is leading us to think that this is an internal DSS problem within the tcp transport layer. 

                Even after all of our dss services on the server are stopped leaving just the dss system services – the cpu issue remains


                    This is a critical issue that could be blocking a year's worth of work.  Is there a developer I can talk to to help resolve this?

    Thanks

    Friday, October 7, 2011 7:08 PM

Answers

  • An issue was found in R3 (and earlier versions) that caused the CPU to spike on the teardown of an unsecured TCP transport. This has been fixed and will be part of the forthcoming v4 release.

    Tuesday, November 22, 2011 5:17 PM
    Moderator

All replies

  • This has been referred to a developer to investigate. I have also responded via LinkedIn.

    Trevor

     

    Monday, October 10, 2011 5:23 AM
  • An issue was found in R3 (and earlier versions) that caused the CPU to spike on the teardown of an unsecured TCP transport. This has been fixed and will be part of the forthcoming v4 release.

    Tuesday, November 22, 2011 5:17 PM
    Moderator