Latest release of The Server Framework: 6.9.2

Version 6.9.2 of The Server Framework was released today.

This release includes changes to support Visual Studio 2017 (15.9), Visual Studio 2019 (16.2), design changes to the PerfMon tools library to improve performance and some bug fixes.

As always, see the release notes here, for full details of all changes.

Bug fixes:

  • Bug fix to JetByteTools::Win32::TimeChangeNotificationMonitor and JetByteTools::Win32::CSystemShutdownMonitor so that we don’t truncate the pointer passed SetWindowLongPtr(). Truncation was rarely occurring to just the top bits.
  • Bug fix to JetByteTools::Win32::CSystemTime so that we correctly set times and dates that are in the past in the presence of daylight savings time differences between ’now’ and the date/time being set.
  • Bug fix to JetByteTools::IO::CBufferChainStoresNulls::Dump() so that we walk the buffer chain correctly.
  • Bug fix to CUnsortedBufferProcessor::~CUnsortedBufferProcessor() where we were incorrectly releasing the m_pProcessingBuffer which is used as a ‘marker’ and for which we don’t own a reference.
  • Bug fix to JetByteTools::IO::CSequencedBufferCollection::Purge() so that we reset the next buffer sequence correctly.
  • Bug fix to JetByteTools::Perfmon::CPerformanceDataBlock where we were allowing counters to become unaligned and to span cache lines and this was severely affecting performance.
  • Bug fix to JetByteTools::Service::CShutdownHandler::Run() to fix a bug during shutdown for services that take time to shut down.
  • Bug fix to JetByteTools::WebSocket::CHandshakeParser::OnDataReceived(), we were returning an incorrect value for the number of bytes consumed.
  • Bug fix to JetByteTools::WebSocket::HiBi::CProtocolHandler::AccumulateControlFrameData() where we now remove any unused space at the front of a buffer during processing so that subsequent buffer operations are more likely to find space in the buffer.

Design changes:

  • Changes to allow for multiple kinds of perfmon tools data collection rather than simply collection via a known shared memory segment. We can now create a performance data block internally to the process and expose the counter data via an API to the internals of the process. This lets the process itself define an API for viewing its performance counters and allows us to support things like Prometheus on Linux in addition to the normal PerfMon collection on Windows.
  • Changes to allow for monotonic counters that are also exposed as a ‘per second’ counter to be managed as a single counter using JetByteTools::PerfMon::CCPerformanceDataSchema::AddLinkedPerSecondCounter(). This call creates a per second counter that is linked to the counter that was added immediately prior to this call. The per second counter is exposed for collection as a distinct counter but this simply points to the same physical counter as the linked monotonic counter. This reduces the number of counter manipulation calls that need to be made and improves performance.