TCP error 995

648 views
Skip to first unread message

Ramon

unread,
Nov 17, 2011, 5:39:31 AM11/17/11
to agatha

Hi all,

I'm getting the following error:

A TCP error (995: The I/O operation has been aborted because of either
a thread exit or an application request) occurred while transmitting
data.

I have a WCF front-end service which calls a back-end service.
Communication between these service is done with Agatha and works for
a certain amount of calls. My guess is 100 and then this error is
shown after a while in the log.

I don't really know why this is happening. I am using Agatha Castle
1.3.0.0 via nuget and using net.tcp


Maybe it is because the way I use Agatha is incorrect. Basically I
have this:


public class FrontEndService
{
readonly IRequestDispatcher RequestDispatcher =
Global.Container.Resolve<IRequestDispatcher>();

public string FirstMethod()
{
RequestDispatcher.Send(new UpdateStats("FirstMethod",
DateTime.UtcNow));
return RequestDispatcher.Get<FirstMessageResponse>(new
FirstMessageRequest()).ToString();
}

public string SecondMethod(string val)
{
RequestDispatcher.Send(new UpdateStats("SecondMethod",
DateTime.UtcNow));
return RequestDispatcher.Get<SecondMessageResponse>(new
FirstMessageRequest(val)).ToString();
}
}

I have two questions:
1. RequestDispatcher is NOT a singleton I right?
2. Is RequestDispatcher thread-safe? For example, could I use
Parallel.For to call RequestDispatcher.Add(..)?
3. What the cause of my TCP error 995 could be?
4. Must I call release?

I would like castle to create my WCF front-end service via Castle so
that a IRequestDispatcher instance can be injected so that I do not
have to manage it thus release it as my guess is that not releasing
the RequestDispatcher is the cause of my problems.

Davy Brion

unread,
Nov 17, 2011, 5:44:58 AM11/17/11
to agath...@googlegroups.com
1) no
2) no
3) incorrect assumptions about questions 1, 2 and 4
4) most certainly

my guess is that you're leaving multiple channels open, and when the server limit is reached, you can get exceptions like the one you're getting.  The wcf proxy (and thus the channel) is closed when the RequestDispatcher is disposed.  Castle does this when you Release the resolved component.  If you don't do that, the channels remain open, and the server will stop accepting requests once it's ran out of channels

Ramon

unread,
Nov 17, 2011, 5:55:19 AM11/17/11
to agatha
> my guess is that you're leaving multiple channels open, and when the server
> limit is reached, you can get exceptions like the one you're getting.  The
> wcf proxy (and thus the channel) is closed when the RequestDispatcher is
> disposed.  Castle does this when you Release the resolved component.  If
> you don't do that, the channels remain open, and the server will stop
> accepting requests once it's ran out of channels

That was my guess to because it stopped after about 100 requests.
Wanted to make sure that my current implementation would be bad.

Thanks for your fast response!

--
Ramon

Ramon

unread,
Nov 17, 2011, 7:19:09 AM11/17/11
to agatha

Releasing the RequestDispatcher fixed my bug. I now use Windsor WCF
Facility to create the service and let it inject the
IRequestDispatcher and Windsor now does the resolving and releasing
for me and it is worked perfect!

--
Ramon
Reply all
Reply to author
Forward
0 new messages