In my application, I am using client.open and client.close to open a WCF proxy channel, use the wcf method and finally close it. I do this is several parts of my Windows Forms application.
However, I have noticed that client.close does not necessarily close the connection immediately. Why is this? Should I use client.Abort instead?
Am I using the WCF client the right way? i.e. clien.open -> call WCF method -> client.close.
Thanks for any help in advance!
Subbu
The .Close() method will try to close the connection gracefully, e.g. a pending call will still be finished by the server, and only after that's done, the connection is terminated. Use this whenever possible - it's the gentle and preferred way of closing a client connection.
.Abort() really just tears down the communication channel - not matter whether a call is still in progress or not. It's the ultimate, last resort escape hatch, if .Close() failed.
As a best practice, I would wrap my service calls into a try...catch block, something like this:
try
{
myServiceClient.CallSomeMethod();
myServiceClient.Close();
}
catch(FaultException<SomeError>)
{
myServiceClient.Abort();
}
// possibly other catch clauses, too - call .Abort() inside them
catch(CommunicationException)
{
myServiceClient.Abort();
}
Related
I have a WCF method.
I would like to return to user a result and continue processing in the server side (via .net Task).
The problem is that I have the "Cannot access a disposed object." error message when I continue processing in the server side.
can anyone help ? how can I implement that. Return a result to user but continue working in the server side.
thanks
Hagai
explore callback contract option for your scenario - http://www.dotnetcurry.com/ShowArticle.aspx?ID=721
I do asynchronous requests in LoadState method of a certain Page. I use HttpClient to make a request and I expect the splashscreen to go away while I await the result.
If I am not connected to any networks, the splashscreen immediately goes away and I get a blank page because the request obviously didn't happen.
But if I am connected to a network but have connectivity issues (for example, I set a wrong IP address) it seems to start a request and just block.
My expectation was that the HttpClient would realize that it cannot send a request and either throw an exception or just return something.
I managed to solve the issue of blocking by setting a timeout of around 800 milliseconds, but now it doesn't work properly when the Internet connection is ok. Is this the best solution, should I be setting the timeout at all? What is the timeout that's appropriate which would enable me to differentiate between an indefinitely blocking call and a proper call that's just on a slower network?
I could perhaps check for Internet connectivity before each request, but that sounds like an unpredictable solution...
EDIT: Now, it's really interesting. I have tried again, and it blocks at this point:
var rd = await httpClient.SendAsync(requestMsg);
If I use Task.Run() as suggested in the comments and get a new Thread, then it's always fine.
BUT it's also fine without Task.Run() if there is no Internet access but the network access is not "Limited" (it says that the IPv4 connectivity is "Internet access" although I cannot open a single website in a browser and no data is returned from the web service. It just throws System.Net.Http.HttpRequestException which was something I was expecting in the first place) Only blocks when the network connection is Limited.
What if instead of setting a timeout, you checked the connection status using
public static bool IsConnected
{
get
{
return NetworkInformation.GetInternetConnectionProfile() != null;
}
}
This way if IsConnected, then you make the call; otherwise, ignore it.
I'm not sure if you are running this in App.xaml.cs? I've found requests made in that class can be fickle and it may be best to move the functionality to an extended splash screen to ensure the application makes it all the way through the activation process.
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh868191(v=win.10).aspx
I'm using Netty to write a client application that sends UDP messages to a server. In short I'm using this piece of code to write the stream to the channel:
ChannelFuture future = channel.write(request, remoteInetSocketAddress);
future.awaitUninterruptibly(timeout);
if(!future.isDone()){
//abort logic
}
Everything works fine, but one thing: I'm unable to test the abort logic as I cannot make the write to fail - i.e. even if the server is down the future would be completed successfully. The write operation usually takes about 1 ms so setting very little timeout doesn't help too much.
I know the preffered way would be to use an asynch model instead of await() call, however for my scenario I need it to be synchronous and I need to be sure it get finnished at some point.
Does anyone know how could I simulate an uncompleted future?
Many thanks in advance!
MM
Depending on how your code is written you could use a mock framework such as mockito. If that is not possible, you can also use a "connected" UDP socket, i.e. a datagram socket that is bound to a local address. If you send to a bogus server you should get PortunreachableException or something similar.
Netty has a class FailedFuture that can be used for the purpose of this,
You can for example mock your class with tests that simulate the following:
ChannelFuture future;
if(ALWAYS_FAIL) {
future = channel.newFailedFuture(new Exception("I failed"));
else
future = channel.write(request, remoteInetSocketAddress);
I am just learning WCF and wrote a Windows Service hosting a WCF service. Ever since I started it in service.msc in the remote server (physically remote, and very slow) I think I have already hit and fixed like a hundred errors here and there already. I am now finally stuck.
At this point, I have enabled tracing and message logging. The first and only function call looks like this:
[OperationContract]
public MyServiceResponse ConnectToAXDynamicsViaDotNET2BusinessConnectorWithSadFace()
{
try
{
throw new NotImplemented();
}
catch(Exception ex)
{
return new MyServiceResponse(ex, ex.Message);
}
}
[DataContract]
public class MyServiceResponse
{
// ...
}
Upon calling the operation, the client just sits and waits until timeout. Checking the trace, it records my thrown exception. So it makes me wonder if WCF actually blocks there and ignore my catch clause.
I then tested with just a simple return value without throwing and it FINALLY works.
My question is, how then can I make the above scenario work, ie. catch the exception and return a sensible result back to client? Maybe it's just the tracing that blocks me, but I want to enable tracing during this whole debugging process otherwise it's really hard to work.
Thanks for your precious help!
EDIT: Sorry, I found this right after I posted this question. Happens all the time: http://msdn.microsoft.com/en-us/library/ee942778.aspx but I have yet to read it as I got to run off now. Not sure it it will solve my problem.
Risk being downvoted, but just for documentation sake and general usefulness of having this question:
Through reading the FaultException handling articles, I guess the above behavior is due to Exception class not serializable. And the service silently disconnects itself without returning any error messages eventhough the "send (unknown) faults to client" is enabled. As for why it does so, I have no idea yet. Will update if I find out more.
I have since changed to throw new FaultException() instead of returning my own MyServiceResponses.
I had a connection working but something changed and now the data isn't showing up. It is a simple query that worked before that just returns all entities. I put in break points on the LoadOperation call and it fires and gets 0 entities. I also put a break point on the service itself, and it does not break before the LoadOperation evaluates. After the LoadOperation completes, then the service query is called... well after we needed the data. The only thing that I can think of that could be a problem is that I added 2 WCF services to the solution. Would WCF services stop the RIA from working? Any ideas on what else could cause the problem?
Client:
LoadOperation<Project> loadOp =
this._projectContext.Load(this._projectContext.GetProjectsQuery());
Service:
public IQueryable<Project> GetProjects()
{
return this.Context.Projects;
}
See, real basic, but not working.
You need to put a callback method on your Load operation and then check the results of the LoadOperation.Error when it comes back. In that error you will find the exception which will let you know what the problem is (you will probably have to check the inner exception to get the full details).