Hello Folks,

I have encountered a problem when I try to open MAMOs from the workstation using Streaming. When I double-click the studio a window is opened with this message (An unexpected error occurred on a receive.) I don't understand why, because when I open other modalities (such CT or MR) it works correctly. Also, if I retrieve the MAMO instead of using streaming, it works correctly.

This what the log tells:

(My log is in Spanish, the English error is:

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive.)

 

Unexpected exception processing thread pool item.
System.Net.WebException: Se ha terminado la conexión: Error inesperado de recepción. ---> System.IO.IOException: No se puede escribir datos de en la conexión de transporte: Se ha forzado la interrupción de una conexión existente por el host remoto. ---> System.Net.Sockets.SocketException: Se ha forzado la interrupción de una conexión existente por el host remoto
   en System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   en System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- Fin del seguimiento de la pila de la excepción interna ---
   en System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   en System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   en System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- Fin del seguimiento de la pila de la excepción interna ---
   en System.Net.HttpWebRequest.GetResponse()
   en ClearCanvas.Dicom.ServiceModel.Streaming.StreamingClient.RetrievePixelData(String serverAE, String studyInstanceUID, String seriesInstanceUID, String sopInstanceUid, Int32 frame, FrameStreamingResultMetaData& metaInfo)
   en ClearCanvas.Dicom.ServiceModel.Streaming.StreamingClient.RetrievePixelData(String serverAE, String studyInstanceUID, String seriesInstanceUID, String sopInstanceUid, Int32 frame)
   en ClearCanvas.ImageViewer.StudyLoaders.Streaming.StreamingFrame.CreateNormalizedPixelData()
   en ClearCanvas.ImageViewer.StudyManagement.Frame.GetNormalizedPixelData()
   en ClearCanvas.ImageViewer.StudyManagement.VisibleDisplaySetPrefetchingStrategy.PrefetchPixelData(IDisplaySet displaySet)
   en ClearCanvas.ImageViewer.StudyManagement.VisibleDisplaySetPrefetchingStrategy.<>c__DisplayClass2.b__0()
   en ClearCanvas.Common.Utilities.SimpleBlockingThreadPool.ProcessItem(SimpleBlockingThreadPoolDelegate del)
   en ClearCanvas.Common.Utilities.BlockingThreadPool`1.RunThread()
2010-08-27 11:15:15,781 [Pool 36] ERROR - Excepción lanzada.

 

Thank you very much in advance!

Looking in the Server Logs I've seen one interesting thing:

2010-08-30 10:32:31,453 [Streaming (client: 192.168.1.224:3413)] ERROR - Exception thrown
System.Net.HttpListenerException: Recursos insuficientes en el sistema para completar el servicio solicitado
en System.Net.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 size)
en ClearCanvas.ImageServer.Services.Streaming.ImageStreaming.WADORequestProcessor.SendWADOResponse(WADOResponse response, HttpListenerContext context)
en ClearCanvas.ImageServer.Services.Streaming.ImageStreaming.WADORequestProcessor.HandleRequest(HttpListenerContext context)
en ClearCanvas.ImageServer.Services.Streaming.Shreds.ImageStreamingServer.OnHttpRequestReceived(Object sender, HttpRequestReceivedEventArg args)

The exception is:

System.Net.HttpListenerException: Insufficient system resources exist to
complete the requested service

The server has got 16GB of ram and is 64 bits, so I don't thing that is true. Indeed, I have tried with the same MAMO in other server that only has 4 GB of RAM and it works. So I supose that is a matter of a quotation or configuration.

Thank you!

Based on the logs, it looks like the client is experiencing an OutOfMemoryException when trying to allocate a buffer to store the pixel data it is retrieving from the server. The only other thing I can suggest is to play with the max buffer size setting(s) on the server and the client. The binding name is BasicHttpBinding_IHeaderStreamingService in both the server and client configuration file. However, I'm pretty sure it's a memory allocation issue on the client.

Have you tried it with a different client machine?

Thank you for answering Stewart.

We are still having the same problem, we have tried to play with the max buffer size, but with no luck.

This is happening in an installation with this scenario:

3 PACS ImageServer

4 or 5 clients

2 PACS are in the same subnet, and the other in a different one (connected through VPN).

The problem happens only with the MAMOS, the streaming with the others modalities works ok. And it happens with all the clients (different machines). The mamos seems to be ok, because if we retrive one to our office it works ok in our PACS and workstation with streaming and with Q&R.

We are trying a lot of things, all with the same result :-(

Thank you very much for your interest!

How big are the images? I know Fischer mammos can be somewhere around 45MB, which is pretty big, but not ridiculous. I have successfully streamed those, though. The only other things I can suggest are:

- try reducing the concurrency for streaming pre-fetching, which I believe is 5 threads by default. It might reduce the load.
- try removing any antivirus software from the clients; we have actually seen streamed images get corrupted by ESET NOD32 so they looked messed up in the client. Their support people would neither confirm or deny this as a problem, but they were definitely not helpful.

Both of these are a stretch, but I don't know what else to suggest at this point. If I think of anything, I'll let you know.

Hello again,

I'm still stuck with this problem, but I've got more information that I would like to share with you.

The Image Server is installed in 3 different servers (with different hardware)  all of them with Windows Server 2003 R2 64bits.

What I've done, is to install a fresh Windows 2003 Server R2 64 bits in my office in a regular PC that I have (in order to discard the network).

I have been able to reproduce the error with the same behaviour that in the hospital. And it happens with MAMMOS that  bigger than 6 MB. With MAMMOS of 12 MB fails, and also with MAMOS of 32 MB (the hospital ones).

Now, I can tell that the problem is on the server, because I've tried to call directly the image using WADO directly from the web browser, and it doesn't work, and the server log tells the same (System.Net.HttpListenerException: Insufficient system resources exist to complete the requested service).

I've been trying a lot changing values in the BasicHttpBinding_IHeaderStreamingService section of the config file (both files) with no luck.

We have other 64 bits installation over Windows 2008 Server 64 bits and everything works correctly. So I suppose that is something related to the Windows 2003 64bits.

Anyone has tried the ImageServer in Windows 2003 Server 64 bits with MAMMOS ?

We have no antivirus.

 

Thank you very much Stewart

 

A late reply to an old post...

This is one of those standard but annoying effects you get as most HTTP servers have default upload limits out-of-the-box: These are set like this as typically Denial Of Service attacks on servers either demand massive numbers of small transactions or many large transactions. The large transactions are more efficient as the servers buffers fill very quickly which you've noticed in your very own simulated DOS attack, the entity requests have maxed the allowed buffers space so it just collapses, at least it's collapsing relatively gracefully!

IIS6 uses MaxRequestEntityAllowed and the default maximum is 4GB, you'll also find that in metabase.xml AspMaxRequestEntityAllowed defaults to 200000bytes of data. Change them and you should be good to go as they are the fairly basest buffer settings for file size handling.

If you are unfortunate enough to be using IIS7 then it gets worse as appcmd set config / section:asp has MaxRequestEntityAllowed set to 200000 bytes of data. Again change both to exceed your typical expectation.

Not really applicable here but Apache has a standard default of 2GB set in the LimitRequestBody variable.

So the server element is fixable just by changing some of the base settings.

If you happen to be using a web base for a query, WADO springs to mind here,  then there is also a 2gb limit inbuilt into IE6 that rises to 4GB on the newer series. Typically the worksaround is to use an activex extension as the viewer platform, personally I don't like such proprietry fixes. Java is a little better as it works on most browsers.

BTW the mammo images my modalities produce are 63.5 MB per image, FFDM does produce superb images but at a cost.

Nick,

Just a quick follow up on this. The server side code that is failing in this case is not hosted within IIS, rather it is a .NET HttpListener class hosted in our ShredHostService that is failing.

Steve