Can you send me sample to demonstrate? On Aug 30, 2010, at 11:12 PM, Daniel Richardson wrote:
> Craig, > > Yes, that's the code and the channel is aborted. This however must > leave the session attached/active (or something) because after the > client then makes 10th consecutive call the next call times out due to > exceeding maxConcurrentSessions. > The PerformInvocation method in WcfRemotingInterceptor then throws a > TimeoutException as the service is no longer responding due to no more > sessions being available. A client call cannot be made then until a > session times out on the service freeing one up. > I can send a simple solution to demonstrate the issue. > > Thanks Daniel > > On Aug 30, 8:03 pm, Craig Neuwirt <[email protected]> wrote: >> Hey Daniel, >> >> Isn't the code in question something like >> >> try >> { >> if (timeout.HasValue) >> { >> >> comm.Close(timeout.Value); >> } >> else >> { >> comm.Close(); >> } >> } >> catch >> { >> comm.Abort(); >> } >> >> If an exception occurs, the channel should be aborted. Is there something >> else that needs to be >> done to close it properly? >> >> thanks, >> craig >> >> On Aug 30, 2010, at 1:15 AM, Daniel Richardson wrote: >> >> >> >>> True, it isn't bubbling up but this means the communication channel >>> isn't being closed properly and aborted. >>> This in itself wouldn't be too much of a problem but if you have a >>> default WCF configuration then for a service the >>> maxConcurrentSessions="10". If you then make the same service call >>> repeatedly in succession then after the 10th call the WCF service then >>> times out due to all the sessions being taken up, due to the channel >>> not being successfully released. >>> This then is a problem. The maxConcurrentSessions can be increased but >>> this isn't correcting the issue. >> >>> On Aug 27, 7:37 pm, Craig Neuwirt <[email protected]> wrote: >>>> Zero is chosen to avoid excessive waiting on disposal. It is in a >>>> try/catch block so it shouldn't be bubbling up. >> >>>> On Aug 27, 2010, at 4:49 AM, Daniel Richardson wrote: >> >>>>> The WcfChannelHolder class though doesn't appear to use this value. >>>>> Both the RefreshChannel and Dispose method are hardcoded to use >>>>> TimeSpan.Zero when calling WcfUtils.ReleaseCommunicationObject?? >> >>>>> On Aug 27, 1:07 pm, John Simons <[email protected]> wrote: >>>>>> Hi Daniel, >> >>>>>> When you add the wcffacility to the container you can specify the >>>>>> timeout: >>>>>> container.AddFacility<WcfFacility>(f => f.CloseTimeout = TimeSpan.Zero) >> >>>>>> Cheers >>>>>> John >> >>>>>> ________________________________ >>>>>> From: Daniel Richardson <[email protected]> >>>>>> To: Castle Project Users <[email protected]> >>>>>> Sent: Fri, 27 August, 2010 2:28:53 PM >>>>>> Subject: WcfIntegration - timeout exception? >> >>>>>> Hi, >> >>>>>> I am using the WcfIntegration client side to instantiate my services. >>>>>> The lifestyle is transient (this is a requirement of my design) so I >>>>>> understand that I need to manage the lifecycle of the components. I am >>>>>> using the below code to instantiate and call my service (where the >>>>>> ComponentContainer is a wrapper around IWindsorContainer). >> >>>>>> This however results in a call to the Dispose method on >>>>>> WcfChannelHolder, which is throwing an exception due to the call to >>>>>> release the communication object... >>>>>> WcfUtils.ReleaseCommunicationObject(Channel, TimeSpan.Zero); >>>>>> This results in a System.TimeoutException when attempting to close the >>>>>> channel. >> >>>>>> Why is the timeout set to zero? Is anyone else encountering this >>>>>> issue? Can this be made configurable somehow? >> >>>>>> var search = ComponentContainer.Resolve<ISearchService>(); >>>>>> try >>>>>> { >>>>>> var result = search.PolicySearch(new PolicySearchRequest >>>>>> { >>>>>> RiskReference = "abc" >>>>>> }); >>>>>> System.Console.WriteLine("count: " + result.ResultCount); >>>>>> } >>>>>> finally >>>>>> { >>>>>> ComponentContainer.Release(search); >>>>>> } >> >>>>>> Thanks >> >>>>>> -- >>>>>> 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 >>>>>> athttp://groups.google.com/group/castle-project-users?hl=en. >> >>>>> -- >>>>> 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 >>>>> athttp://groups.google.com/group/castle-project-users?hl=en.-Hide quoted >>>>> text - >> >>>> - Show quoted text - >> >>> -- >>> 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 >>> athttp://groups.google.com/group/castle-project-users?hl=en.- Hide quoted >>> text - >> >> - Show quoted text - > > -- > 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. > -- 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.
