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 <[email protected]> wrote: > On Tue, Jun 23, 2009 at 10:16 AM, Grant <[email protected]> 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. > > > On Jun 23, 2:55 pm, Craig Neuwirt <[email protected]> wrote: > > > On Tue, Jun 23, 2009 at 8:38 AM, Grant <[email protected]> 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: > > > >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? > > > > 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. > > > > > Regards, > > > > Grant. > > > > > On Jun 23, 2:10 pm, Craig Neuwirt <[email protected]> wrote: > > > > > 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 > > > > > > On Tue, Jun 23, 2009 at 4:50 AM, Grant <[email protected]> > > wrote: > > > > > > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
