Proxy recreate on CommunicationException

Jun 2, 2009 at 2:11 PM
Edited Jun 2, 2009 at 2:15 PM

 

First, thank you for this article.  It addresses some of the nagging issues we are dealing with in our development of a large WPF/WCF line of business application, particularly in the area of proxy lifetime and session timeouts.  Articles like these, along with your excellent book, give us mere mortal developers a fighting chance!

I do have some questions/comments about the whitepaper.  The code below is from page 29 of the whitepaper:

try

{

// use the proxy here

}

catch (CommunicationException comEx)

{

FaultException faultEx = comEx as FaultException;

if (faultEx != null)

{

throw;

}

// use the proxy again here, if it throws, let it

}

 

Now, at the point where it says “use the proxy again”, I would have a faulted service channel, but not a faulted client channel.  The client will not fault unless I call the proxy again, so the code to handle the faulted event and recreate the proxy (whitepaper Figures 16 & 17) does not come into play here. Therefore, it seems at this point I need to close and recreate the Proxy and retry.  Something like…

 

Figure 2

try

{

Proxy.TryAndDo();

}

catch (CommunicationException comEx)

{

FaultException faultEx = comEx as FaultException;

if (faultEx != null)

{

throw;

}

 

CloseProxy();   pseudo method

RecreateProxy(); pseudo method

Proxy.TryAndDo();

}

 

 

Assuming I am understand this correctly, I would then refer to your comments on page 30 where you mention “significant clutter in the client code” and “creating an exception handling proxy wrapper…… A sample has been provided to illustrate this”.  I would agree with the clutter part, as it seems I would need to wrap every proxy call in the application (as in Figure 2 above) to check for “CommunicationExceptions are not FaultExceptions”.  In my application, this is a lot of coding!

Am I missing something?  Is there in fact a more elegant way to do this?

 Thank you

 

Coordinator
Jun 3, 2009 at 3:12 PM

Hi there!

There are a few scenarios here, all solved by code shown in this example (assumption that you also handle the Faulted event to recreate the proxy):

void Item_PropertyChanged(object sender, PropertyChangedEventArgs e) {

try{

     TodoItem item = (TodoItem)sender;

     try {

          _Proxy.UpdateItem(item);

     }

     catch (CommunicationException commEx) {

          FaultException faultEx = commEx as FaultException;

          if (faultEx == null)  {

               _Proxy.UpdateItem(item);

          }

          else  throw;

          }

 

     }

     catch (Exception ex) {

          MessageBox.Show(ex.ToString());

     }

}

 a) You use the proxy, during the two-way call the service channel is faulted, the exception received at the client is a CommunicationException (not a FaultException). You create a new instance of the proxy in the Faulted handler, and your code retries as shown above.

b) You use the proxy, during the one-way call the service channel is faulted. No exception to the client (yet), nothing to do (yet). Next time you use the proxy a) happens.

c) The session times out and faults the service channel. No exception to the client (yet), nothing to do (yet). Next time you use the proxy a) happens.

I have not yet come up with a scenario that doesn't work with this model, but please let me know if you come across one.

As for "a better way" I have an error handling proxy wrapper that encapsulates this work. I'm just updating that sample now and posting today along with a webcast that talks through these issues.

Jun 14, 2009 at 11:21 PM

Michele,

Thank you for your response – it helped clarify things for me. I just watched the “Proxies and Exception Handling” Webcast and have one more question. Would it be possible to update the C# samples with the project/solution you were using in that WebCast so we could get a look at your error handling proxy wrapper class?

Thanks,

Tom

Coordinator
Jun 15, 2009 at 12:34 AM

Hi Tom,

I have already posted everything to the site! Did you look at the code samples?

-Michele

From: shallotx [mailto:notifications@codeplex.com]
Sent: Sunday, June 14, 2009 4:22 PM
To: mlb@dasblonde.net
Subject: Re: Proxy recreate on CommunicationException [wcfguidanceforwpf:58215]

From: shallotx

Michele,

Thank you for your response – it helped clarify things for me. I just watched the “Proxies and Exception Handling” Webcast and have one more question. Would it be possible to update the C# samples with the project/solution you were using in that WebCast so we could get a look at your error handling proxy wrapper class?

Thanks,

Tom

Read the full discussion online.

To add a post to this discussion, reply to this email (wcfguidanceforwpf@discussions.codeplex.com)

To start a new discussion for this project, email wcfguidanceforwpf@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.68/2175 - Release Date: 06/14/09 17:54:00

Jun 15, 2009 at 1:20 AM

Well, I have the WCFGuidanceForWPFDevelopers_CSharp.zip dated May 28, but I don’t see the error handling proxy wrapper being used anywhere. Perhaps I am being dim and looking in the wrong place?

Coordinator
Jun 15, 2009 at 2:44 AM

I misunderstood you Tom! There is a separate download with the full code base for the exception handling proxy wrapper. What I did is create an add-in that automates it! So you can generate the code for any proxy you like! See the link to the Exception Handling WCF Proxy Generator on the home page of this codeplex site!

Jun 22, 2009 at 2:24 PM

Michelle,

Thank you. I have the proxy wrapper and am doing some testing now. You had asked in a previous post about scenarios that don’t work with this model, so I wanted to update you on something I am testing.

I am using NetTCPBinding. I make a call to the service, and then wait 10 minutes. By this time the service will have timed out (based on the default). So on my next call, the proxy wrapper does it’s magic, recreates the proxy, and tries to invoke the method again. If fails, and gets caught in the final catch (TargetInvocationException targetEx2)”, where I now have “The socket connection was aborted …..”, which, at this point, I am showing to the user. I do at this point however, have a good proxy, and could potentially continue.

It looks like this is the expected behavior. Might I have missed something here? If not, it seems I still need a process for dealing with session timeouts, as I would prefer for the user not to have to see these timeout messages.

Thanks,

Tom

Coordinator
Jun 22, 2009 at 4:57 PM

Hi Tom,

I just ran a test with netTcpBinding to make sure - and the behavior I see is as I expected:

a) Session times out

b) client code tries to use the proxy, the call fails for the timeout

c) it goes through OnFaulted() and recreates the proxy

d) it retries the call, and the call succeeds

If the call fails a second time, you might be stopping on a breakpoint that the session timed out again? Or, perhaps the service channel is not available for another reason? Email me at mlb[at]dasblonde.net (replace [at] with @ of course) and I'll send you this working sample that uses TCP so you can compare notes.

-Michele