Divyesh, just to set your expectations, this thread is 9 years old, you aren't likely to get a response.
On Tue, May 15, 2018 at 10:28 AM Divyesh Chapaneri <divyesh1...@gmail.com> wrote: > 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. > > http://www.kiwidude.com/WcfDemo.zip > <http://www.google.com/url?q=http%3A%2F%2Fwww.kiwidude.com%2FWcfDemo.zip&sa=D&sntz=1&usg=AFQjCNHTPIGeFWb5mgNKm3H-bVHj_DQoig> > > Thanks, > Divyesh > > On Friday, June 26, 2009 at 10:12:13 PM UTC+10, Craig Neuwirt wrote: >> >> >> >> 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 >> >> >>> Thanks, >>> Grant. >>> >>> On Jun 23, 4:26 pm, Craig Neuwirt <cneuw...@gmail.com> wrote: >>> > On Tue, Jun 23, 2009 at 10:16 AM, Grant <grant.dr...@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. >>> > >>> > > On Jun 23, 2:55 pm, Craig Neuwirt <cneuw...@gmail.com> wrote: >>> > > > On Tue, Jun 23, 2009 at 8:38 AM, Grant <grant.dr...@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: >>> > > > >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 <cneuw...@gmail.com> 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 <grant.dr...@gmail.com> >>> > > 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 unsubscribe from this group and stop receiving emails from it, send an > email to castle-project-users+unsubscr...@googlegroups.com. > To post to this group, send email to castle-project-users@googlegroups.com > . > Visit this group at https://groups.google.com/group/castle-project-users. > For more options, visit https://groups.google.com/d/optout. > -- 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-users+unsubscr...@googlegroups.com. To post to this group, send email to castle-project-users@googlegroups.com. Visit this group at https://groups.google.com/group/castle-project-users. For more options, visit https://groups.google.com/d/optout.
