Help please - CommunicationException issues with WCF...

941 views
Skip to first unread message

Grant

unread,
Jun 23, 2009, 5:50:40 AM6/23/09
to Castle Project Users
The problem I am experiencing is that if I leave my WCF service host
running idly for a period (beyond the binding receive timeout?) then I
find that subsequent method invocations from the client can result in
a stream of "CommunicationException" ,
"CommunicationObjectAbortedException", "IOException" and
"SocketException" messages occuring inside .NET. If I retry the
activity then (most of the time) it will subsequently succeed.

It is as if the proxy instance that the Windsor WCF client returns is
becoming invalid, but rather than silently destroying it and creating
a new one it lets the error flow through and instead creates a new one
one on the next request. Does that make any sense?

Is anyone out there actually using this facility in a production non-
web application? The documentation is non-existent, the few examples I
have seen are either web app based, out of date or too simple to be
useful (as are the unit tests). I'm banging my head against the wall
with this - it could be something really dumb I am doing in my usage
but without relevant examples it is impossible to know. I'm very close
to giving up on WCF and going back to "trusty" .NET remoting.

I have posted a small repro project showing how I register the service
hosts and client which you can download from here:
http://www.kiwidude.com/WcfDemo.zip

Here is an example exception stack trace of the exception...

System.ServiceModel.CommunicationException: The socket connection was
aborted. This could be caused by an error processing your message or a
receive timeout being exceeded by the remote host, or an underlying
network resource issue. Local socket timeout was '00:10:00'. --->
System.IO.IOException: The write operation failed, see inner
exception. ---> System.ServiceModel.CommunicationException: The socket
connection was aborted. This could be caused by an error processing
your message or a receive timeout being exceeded by the remote host,
or an underlying network resource issue. Local socket timeout was
'00:10:00'. ---> System.Net.Sockets.SocketException: An existing
connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset,
Int32 size, SocketFlags socketFlags)
at System.ServiceModel.Channels.SocketConnection.Write(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.SocketConnection.Write(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[]
buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager
bufferManager)
at System.ServiceModel.Channels.BufferedConnection.Write(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
at System.ServiceModel.Channels.ConnectionStream.Write(Byte[]
buffer, Int32 offset, Int32 count)
at System.Net.Security.NegotiateStream.StartWriting(Byte[] buffer,
Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer,
Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
--- End of inner exception stack trace ---
at System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer,
Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.Write(Byte[] buffer, Int32
offset, Int32 count)
at System.ServiceModel.Channels.StreamConnection.Write(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
--- End of inner exception stack trace ---

Server stack trace:
at System.ServiceModel.Channels.StreamConnection.Write(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
at System.ServiceModel.Channels.StreamConnection.Write(Byte[]
buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout,
BufferManager bufferManager)
at System.ServiceModel.Channels.FramingDuplexSessionChannel.OnSend
(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.OutputChannel.Send(Message message,
TimeSpan timeout)
at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request
(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action,
Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object
[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action,
Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object
[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService
(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage
message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage
(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke
(MessageData& msgData, Int32 type)
at WcfDemo.Common.Interfaces.IFooService.GetFooStuff()
at
IFooServiceProxy2a1d2ae2b1bc4e319a4a501297fcaa83.InvocationGetFooStuff_79.InvokeMethodOnTarget
()
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at
Castle.Facilities.WcfIntegration.WcfManagedChannelInterceptor.Intercept
(IInvocation invocation)
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at IFooServiceProxy2a1d2ae2b1bc4e319a4a501297fcaa83.GetFooStuff()
at WcfDemo.WinClient.MainForm.OnCallFooButtonClick(Object sender,
EventArgs e) in C:\Dev\Misc\WcfDemo\WcfDemo.WinClient\MainForm.cs:line
23

Craig Neuwirt

unread,
Jun 23, 2009, 9:10:38 AM6/23/09
to castle-pro...@googlegroups.com
Assuming you are using trunk of WCF Facility, the behavior of the proxy is to first ensure that the channel is not closed or faulted.  If it is, it will create a new channel.  If connection to the service host is lost for some reason, but the channel still reports it is ok then you will get an exception an the channel will be recreated the next time.

Is it possible for you to do a test and just create a proxy directly from the ChannelFactory and see if you get the same behavior?

craig

Grant

unread,
Jun 23, 2009, 9:38:31 AM6/23/09
to Castle Project Users
Hi Craig,

Thanks for teh reply. Yes I am using the trunk of the facility (and
2.0 of Castle Windsor). Indeed if I drectly create the service on the
client using the ChannelFactory, everything works and that error does
not occur. You can still see a bunch of
CommunicationObjectAbortedException errors occurring in the background
in the trace window (5 seconds after the call, coincidentally 5
seconds being my receive timeout?). However at least the method
invocation itself succeeds the next time.

Demo repro project updated here:
http://www.kiwidude.com/WcfDemo.zip

So, does it appear then that the WcfClient container stuff isn't
really doing the job we need. Easily fixable or should we work around
it using the ChannelFactory approach instead?

And what is with all those exceptions in the trace window - is
something not being closed properly or is it a .NET WCF thing?

Regards,
Grant.
> > IFooServiceProxy2a1d2ae2b1bc4e319a4a501297fcaa83.InvocationGetFooStuff_79.I­nvokeMethodOnTarget
> > ()
> >   at Castle.DynamicProxy.AbstractInvocation.Proceed()
> >   at
> > Castle.Facilities.WcfIntegration.WcfManagedChannelInterceptor.Intercept
> > (IInvocation invocation)
> >   at Castle.DynamicProxy.AbstractInvocation.Proceed()
> >   at IFooServiceProxy2a1d2ae2b1bc4e319a4a501297fcaa83.GetFooStuff()
> >   at WcfDemo.WinClient.MainForm.OnCallFooButtonClick(Object sender,
> > EventArgs e) in C:\Dev\Misc\WcfDemo\WcfDemo.WinClient\MainForm.cs:line
> > 23- Hide quoted text -
>
> - Show quoted text -

Craig Neuwirt

unread,
Jun 23, 2009, 9:55:30 AM6/23/09
to castle-pro...@googlegroups.com
On Tue, Jun 23, 2009 at 8:38 AM, Grant <grant...@gmail.com> wrote:

Hi Craig,

Thanks for teh reply. Yes I am using the trunk of the facility (and
2.0 of Castle Windsor). Indeed if I drectly create the service on the
client using the ChannelFactory, everything works and that error does
not occur. You can still see a bunch of
CommunicationObjectAbortedException errors occurring in the background
in the trace window (5 seconds after the call, coincidentally 5
seconds being my receive timeout?). However at least the method
invocation itself succeeds the next time.

That's strange since the wcf interceptor is just checking if the channel is alive
and forwarding the request.
 


Demo repro project updated here:
So, does it appear then that the WcfClient container stuff isn't
really doing the job we need. Easily fixable or should we work around
it using the ChannelFactory approach instead?

Not sure what the problem is, but if I can easily reproduce in test case it should be
fixable.  I download your example when i get a chance and try it out


 And what is with all those exceptions in the trace window - is
something not being closed properly or is it a .NET WCF thing?

I suspect WCF since the facility doesn't really get involvedm but WCF
is a mystery so you never know.

 

Craig Neuwirt

unread,
Jun 23, 2009, 10:29:48 AM6/23/09
to castle-pro...@googlegroups.com
Hey Grant,

  Took a quick look at your demo (very nice to test with) and as I suspected, the problem is intrinsic to WCF.   The reason the example using ChannelFactory directly worked is because your creating a new proxy for every request.  When I changed it to reuse the proxy the same exact error occurred.  This is the same problem if you were to stop and restart the service.  I don't know of any way WCF will communicate the connection disruption to the client side.  If it could, I would be able to detect it and recreate channel which is why it works on the next call.

I have some drastic ideas on how to possibly overcome this, but that will great complicate the facility and take a little time for me to complete.  So if you do need this now, you can always make the client services transient and just resolve them when you need to use them.

craig

On Tue, Jun 23, 2009 at 8:38 AM, Grant <grant...@gmail.com> wrote:

Grant

unread,
Jun 23, 2009, 11:16:07 AM6/23/09
to Castle Project Users
Hi Craig,

Sounds like you can do some digging then - hopefully the demo project
should help with the repros.

In the meantime I have given up on the WCF client facility and instead
going with the ChannelFactory approach. I have put it in my service
locator implementation so it is all transparent to the rest of the
code so achieves the same intent as the WCF client. Also seems to be
noticeably more performant too for some reason. I took the opportunity
to also do a Remoting wrapper as well so we can switch to that if we
hit any more WCF gotchas.

From the unit test examples I saw in Castle, the proxy being returned
from the ChannelFactory<T> is not being closed/disposed of in any way
after the method invocation on it. Is that perfectly fine or is it an
object that needs to be disposed of? Just want to make sure we don't
chew up resources in the client if we can indeed get away with letting
the object be normally garbage collected when the method is out of
scope...

Grant.

On Jun 23, 2:55 pm, Craig Neuwirt <cneuw...@gmail.com> wrote:
> > > - Show quoted text -- Hide quoted text -

Craig Neuwirt

unread,
Jun 23, 2009, 11:26:00 AM6/23/09
to castle-pro...@googlegroups.com
On Tue, Jun 23, 2009 at 10:16 AM, Grant <grant...@gmail.com> wrote:

Hi Craig,

Sounds like you can do some digging then - hopefully the demo project
should help with the repros.

In the meantime I have given up on the WCF client facility and instead
going with the ChannelFactory approach. I have put it in my service
locator implementation so it is all transparent to the rest of the
code so achieves the same intent as the WCF client. Also seems to be
noticeably more performant too for some reason. I took the opportunity
to also do a Remoting wrapper as well so we can switch to that if we
hit any more WCF gotchas.

For me, creating a new proxy every time is always slower than using single channel with DP,
but it won't hurt to get some good numbers.  As far as gotchas, if WCF has a gotcha, it is generally
passed on to the facility.  That's the main reason for the facility is to  hide the numerous WCF
gotchas.
 


From the unit test examples I saw in Castle, the proxy being returned
from the ChannelFactory<T> is not being closed/disposed of in any way
after the method invocation on it. Is that perfectly fine or is it an
object that needs to be disposed of? Just want to make sure we don't
chew up resources in the client if we can indeed get away with letting
the object be normally garbage collected when the method is out of
scope...

There is no reason to close the channel since it is reused.  When you release the
component, the channel is automatically closed.  If you create the channel explicitly,
you should also Close them explicitly.

Good luck,
  craig

Grant

unread,
Jun 26, 2009, 5:17:57 AM6/26/09
to Castle Project Users
Hi Craig,

Thanks for that - yeah I looked into it a bit more and now understand
that using ChannelFactory<T> I am responsible for the channel lifetime
and hence responsible for closing it. Frankly that approach sucks as
it results in messy code everywhere.

There is a lot to be said for the simple beauty of .NET Remoting,
which I have now reverted back to (not using the Castle Remoting
facility though, as from what I can see it relies on configuration
files which I don't like). If the Castle WCF facility gets "fixed" so
that the demo I built works (or tells me what I did wrong in the demo)
then will give it another spin.

Thanks,
Grant.

On Jun 23, 4:26 pm, Craig Neuwirt <cneuw...@gmail.com> wrote:
> ...
>
> read more »

Craig Neuwirt

unread,
Jun 26, 2009, 8:12:13 AM6/26/09
to castle-pro...@googlegroups.com
On Fri, Jun 26, 2009 at 4:17 AM, Grant <grant...@gmail.com> wrote:

Hi Craig,

Thanks for that - yeah I looked into it a bit more and now understand
that using ChannelFactory<T> I am responsible for the channel lifetime
and hence responsible for closing it. Frankly that approach sucks as
it results in messy code everywhere.

I agree 


There is a lot to be said for the simple beauty of .NET Remoting,
which I have now reverted back to (not using the Castle Remoting
facility though, as from what I can see it relies on configuration
files which I don't like). If the Castle WCF facility gets "fixed" so
that the demo I built works (or tells me what I did wrong in the demo)
then will give it another spin.

As far as the demo goes, you really didn't do anything wrong.  It is the default
behavior of WCF to no expose connection disruptions on the client side which
lead to your exception.   You can fix your demo in the short term now by switching 
yours client services to transients and remeber to ReleaseComponent when your done.  
Since the WCF Facility is all about overcome WCF's intrinsic peculiarities, I will try and
pursue a solution that may make the anomaly totally transparent, but I need to
first determine if it is feasible without breaking too much

thanks for the feedback,
craig

Divyesh Chapaneri

unread,
May 14, 2018, 8:28:37 PM5/14/18
to Castle Project Users
Hi,

Below link is broken. Can you please upload that demo again ?

I am trying to implement interceptor in my WCF and seems not working. WCF works well with Castle Windsor and without interceptor but fails when I implement interceptor.

Divyesh

Jonathon Rossi

unread,
May 15, 2018, 6:35:13 AM5/15/18
to castle-pro...@googlegroups.com
Divyesh, just to set your expectations, this thread is 9 years old, you aren't likely to get a response.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

Rob H

unread,
Jun 28, 2018, 12:11:36 PM6/28/18
to Castle Project Users
I have a client having a similar issue. They are using Castle Windsor & Entity Framework, IIS, .NET they need better performance on their website.  Is there any U.S. based candidates out there preferably in FL that can do this part time? Send your resume to Rob...@sourceselectgroup.com
Reply all
Reply to author
Forward
0 new messages