Description
Describe the bug
Hello, we have noticed a strange behaviour occurring in DicomSerivce when it receives an HTTP connection request. Total used memory of our application rises to almost 1.5GB compared to normal idling consumption of ~120MB. We have performed tests on 3 different Windows operated machines, with total of 4GB, 32GB and 48GB RAM present, and the peak occupied memory amount remains the same, i.e., it's not trying to consume all the free memory, but always ~1.3GB. The result is the same using fo-dicom v5.0.3 and the latest available v5.1.1.
What is more interesting, is that the connection is not being terminated ever by server, i.e., unless client aborts connection itself the socket remains open and the memory can not be released using GC. Additionally, I have taken 3 snapshots during the profiling run, and another anomaly showed up. When the HTTP connection is "open", there's an additional instance of LOH present in use. Please refer to screenshots for the details
Once the connection is terminated by a client and GC is triggered, the total used memory returns to normal, as you can see from the 3rd screenshot.
The only logs corresponding to actions' timepoints during testing are these 2 lines when client aborts the connection:
[11:07:34 DBG] Read 0 bytes from network stream while reading PDU, connection will be marked as closed
[11:07:34 INF] Connection closed.
At least in our case, this creates a little bit of a problem as our application, which hosts fo-dicom's DicomServer, usually runs in environments with limited resources (4-8GB of RAM in total) and these spikes may create a resources starvation situation, if an automated port scanner or something similar hits the DicomServer and does not terminate the connection itself.
To Reproduce
- Run the instance of
DicomServer<T>. In our case we create it usingdicomServerFactory.Create<CStoreSCP>, whereCStoreSCPis declared likepublic class CStoreSCP : DicomService, IDicomServiceProvider, IDicomCEchoProvider, IDicomCStoreProvider. - Open a new tab in the browser (we've used latest Chrome and Edge in our tests, if that matters) and type in the URL of created
DicomServer, e.g.,http://localhost:104. - Unless you close the tab or terminate an attempt to get a response from the server, the problem will be present
Expected behavior
Either a termination of connection on handshake phase if the connection protocol is incompatible, or later after some timeout if earlier termination not possible.
Screenshots or test DICOM files
Memory graph of profiling session:
Generations' stats from "before", "during" and "after" in corresponding order of snapshots:
Environment
Fellow Oak DICOM version: 5.0.3, 5.1.1
OS: Windows 11, Windows Server 2019
RAM: 4GB/32GB/48GB
Platform: .NET 6
If you will not be able to get the same results during testing, I'd be happy to share a Workspace's dump (judging by other issues, it seems like you also use dotMemory) by any means you find appropriate.
And taking the opportunity, I would like to thank you personally and on behalf of our team for creating and maintaining such an amazing toolset to work with DICOM protocol on so many levels!
Thank you in advance for looking into this!