i am building a WCF Service and i need clients to be able to acquire multiple results in the same time.
For example 5 callings of void UploadPhoto(byte[] photo);
and 1 string GetInfo()
If I understand it correctly, than whenever I do a request for a service, I need to get a response for the first one before the second gets proceeded. Is that correct?
Thanks
You can make multiple calls if you increase the System.Net.ServicePointManager.DefaultConnectionLimit the default is 2.
You need to set the WCF Service as Per-Call Service to process concurrent requests.
That is not quite correct.
If you call a WCF (or other web service) syncronosly then you have to wait for the response before doing anything else.
However, you can call a wcf service asyncronosly, in which case you do not have to wait for the result. You create a handler that handles the result when it comes back, but the main program continues.
Have a look at Ladislav's answer to this question: Difference between WCF sync and async call?
Related
I stuck on this one for about two weeks now - So could someone tell me, is there a limitation from WCF that only one callback at a time can be handled by a callback object? I have tried just about anything I can find in trying to resolve this issue still can't get any place.
I created a very simple app: a client invokes a service then the service makes two callbacks to the client at the same time: callback A, which takes a long time to return; then callback B, calls back repeatedly in a loop even when A is in processing. The problem is, B will never get through when A is in processing. But as soon as A returns, B will get through right away.
Here are the things I have tried:
1. Set ConcurrencyMode to Multiple or Reentrant on both client and service;
2. Set UseSynchronizationContext to False on both client and service;
3. Start service invocation from a worker thread on the client;
4. Creates proxy (service channel) on a worker thread on the client;
5. Start both callbacks on their own worker thread on the service;
6. Making both callbacks as Oneway.
None of these solved issue. The only thing I can think now is that this may be a limitation from WCF. So if someone can shed some light on this it will be greatly appreciated.
Could you try to make an async proxy? When you left click on you're project then clic add Service Reference, then check Generate asynchronous operations.
You will have a client that use event to callback returns. And if I'm not wrong, each callback are done in different threads.
In a client server WCF duplex scenario, what is the recommended way to let the server know that an error occurred on the client side? Let's say that the server notifies one of the clients that it needs to perform a certain operation and an exception is being thrown on the client side.
On the callback interface, I have something like this
[OperationContract(IsOneWay = true)]
void Work(...);
What's the best approach:
Implement a NotifyServer(int clientId, string message) message that the client can call to let the user know that the requested operation failed,
If I set IsOneWay = false on the operation contract, would I have to call every client on a BackgroundWorker thread in order to keep the UI responsive?
Implementing async operations on the server? How will this work? I can generate async operation on the client, will I have to use the same pattern (BeginWork, EndWork) for the client callback method?
Can't think of anything else, because throwing a FaultException on the client side when IsOneWay = true will not work.
Any advice?
Thank you in advance!
Ad 1. That is one way of doing it... recommended if the Work() may take unpredictable amount of time and you do not want your server thread hanging on that call.
Ad 2. You should always perform WCF operations in the background worker and never inside the UI thread.. If you set IsOneWay=False then obviously Work() method will block on the server until it has finished executing on the remote client and returns results. However even if you set isOneWay=true the method will still block on the low-level WCF communication. If WCF connection is dropped, this can be a long time, before you get notified.
Ad 3.
The pattern is up to you.
Example: MSDN: OperationContractAttribute.AsyncPattern Property
No best solution exists. It all depends on your setup (classes, threads, etc). The WCF layer you code should be easy and convenient to use - that is the main guide line.
Am doing some time consuming File operation in WCF web service, so until this call completed i cant make any other service calls from my application.
So i planned use the TPL
Task.Factory.StartNew(() =>
{
CheckFileandCopy(path,fileName);
});
it works, and return true, but the problem is, the completed event doesnt have the actual result, coz the process is running in seperate thread, so am not getting the actual complete event, how i can return the complete event once the task is done, and also how i can make concurrent call when the time consuming method is invoked
You have basically two options:
Do asynchronous calls client side. If you generate a proxy including async methods (for example see this msdn page this would be easy.
Make things asynchronous, server side. This is similar what you did in your example. Only thing missing is the callback with the actual result. For this you can use the duplex scenario where the client is able to receive a call from the service just as if the client is also a service. Note that not all scenario's/bindings support this.
In both cases reading through this msdn article on sessions and concurrency may help with understanding things.
I am trying to create a XAMLX service that I can fire and forget.
But how can I do something like that with a XAMLX? I have no access to the Contract Interface to add the [OneWay] attribute.
I thought that if I did something like
and put the response before the rest of the activities, the service would return at that point but it didn't. It returns only after the whole workflow is completed.
IS it possible to make the service return at that point and than continue with the processing. the other activities would not affect the returned value of the service.
Is it possible to create a fire and forget XAMLX service
Can I somehow make the client fire a normal service as oneWay, if the previous 2 points are not possible?
If you want one-way processing your Receive activity should not have any corresponding SendReply activity.
The reason the response isn't send immediately is the way the workflow scheduler works internally where it waits for the workflow to go idle. Nothing much you can do about the scheduler but if you add a Delay below the SendResponse with a duration of 1 millisecond.
As Ladislav said, remove the SendResponse and you get a one way message.
Not quite sure what you want with fire and forget. If you start a workflow service it will keep on running even if you don't send any more WCF requests to it. Even if it is long running or does other async work. No problems there.
I have a self hosted WCF 4.0 service with an HTTPS endpoint. I have method that writes some trace info after the message comes in. However, some messages are 400k in size, so there is a long wait conceivably between when WCF has it and my console app has it. How can I get a hook or interception layer in there so I can at least know when a message is first coming in?
I think there is a WCF Performance Counter related to this, so there must be some way to know...
Thanks for all ideas!
This is not the same as Detect WCF client open channel operation , this is about knowing when the HTTP traffic first comes in. Maybe its not that I need to monitor things on my WCF service, maybe I need to monitor some other WCF layer that is intercepting HTTP. Can anyone say?
What about making a custom MessageEncoder that simply wraps the default implementation, but overrides ReadMessage() and logs some information before calling the wrapped implementation (which creates a Message instance)? At this stage the full message isn't even fully streamed over the wire, hence it's a very early point of the processing pipeline. Obviously, however, you don't know anything about the message yet. But if you want to get a timestamp, that might be a convenient place to get it.
One option is implement the IDispatchMessageInspector interface for your service with your message size checking code in the AfterReceiveRequest method override. Your code should look something like the code in this blog post.