This forum has been archived. Please start a new discussion on GitHub.

TimeoutException in the IceInternal::TcpTransceiver::read method

I have faced a strange behaviour of the Ice 2.1.2 runtime (Windows XP SP2, VS.NET 2003). It occurs during transmisssion of large data blocks. If we start an application that recieves large data chunks under the VS.NET 2003 debugger, we will see multiple messages in debug output:
First-chance exception at 0x7c81eb33 in server.exe: Microsoft C++ exception: Ice::TimeoutException @ 0x00f8e344.
These exceptions are handled by the Ice runtime without warnings or errors.
The beheviour can be reproduced with the Throughput Ice demo (you need to start the server and the client under the VS debugger). About 10000 TimeoutException exceptions are thrown on a receiving side in a test, which transmits 1000 byte sequences of size 500000.
These exceptions do not influence a correctness of data transmission, however, possibly, not in the best form affect speed of data transmission. Is it possible to investigate the given situation and to make corrections which will eliminate occurrence of exceptions?


  • benoit
    benoit Rennes, France
    Hello Vladimir,

    Yes, these exceptions are expected when using the default thread pool concurrency model on the server side. Although it would be interesting to test if it affects performances, I suspect it doesn't in a large measure since the cost of throwing an exception is minor compared to the cost of reading data over the socket. Also, note that you should get much less exceptions when transmitting data over a network interface instead of the loopback interface.

    In any case, thanks for bringing this to our attention, we'll discuss if this can be changed.

  • Hello, Benoit,

    Yes, this effect does not take place with the Ice.ThreadPerConnection property. I will think over either this concurrency model is acceptable for our applications.
  • benoit
    benoit Rennes, France
    Note that there's nothing wrong with the thread pool model, you can also use it :)! As a matter of fact, the throughput performances of the thread pool and thread per connection concurrency models are quite close.

  • benoit wrote:
    Note that there's nothing wrong with the thread pool model, you can also use it :)!
    I understand this :). There is another issue with this behaviour - it is difficult to track our own exceptions in the debug output.