I have a WCF service operation and I want a call to the operation to start a long running method, however I want the operation to return its result BEFORE the long running method finishes.
I have tried using an IParameterInspector implementation, but the result of the operation is not returned to the client until the long running method has completed.
How should I go about achieving this as anything I start from the operation seems to have to finish before the result is returned to the client?
Thanks.
If you want to do it at the server, take a look at http://blogs.msdn.com/b/carlosfigueira/archive/2011/05/17/wcf-extensibility-ioperationinvoker.aspx, it shows how to bypass the operation (it's a caching scenario, but it can be adapted to your problem).
If you want to do it at the client, you can simply call the operation asynchronously, it will return right away. And when the long-running operation completes, you'll get a notification (callback or event) that its results are ready.
You can't do this with a standard request/response type binding in WCF because as you found out, you won't get a response until the service has completed processing (or times out).
To do what you want, you'll need a service where you can trigger the long running operation and then poll for completion status & response results.
The netMsmqBinding supports this scenario in WCF. All the operations for this binding must be a one-way call since you are only putting a message in a queue for processing. You'll need to have another endpoint or service configured with a request/response binding for the polling method. A good overview of the netMsmqBinding is here.
Related
In ASP.NET Core v2, is the WebSocket returned by HttpContext.WebSockets.AcceptWebSocketAsync thread-safe?
More specifically, can I call ReceiveAsync in parallel with a thread that calls SendAsync?
I'd like to be able to have a message loop receiving messages like the close event, while at the same time be able to send messages in response to server-side events (that is, not in response to received events).
I haven't found any documentation specifying what implementation AcceptWebSocketAsync returns, but in practice it appears to consistently return a ManagedWebSocket instance.
I haven't found any API documentation for ManagedWebSocket. Fortunately the source code has been published and it contains this helpful note:
Thread-safety:
It's acceptable to call ReceiveAsync and SendAsync in parallel. One of each may run concurrently.
It's acceptable to have a pending ReceiveAsync while CloseOutputAsync or CloseAsync is called.
Attemping to invoke any other operations in parallel may corrupt the instance. Attempting to invoke a send operation while another is in progress or a receive operation while another is in progress will result in an exception.
— (source1)
(source2)
tl;dr: not thread-safe in general, but the read and send in parallel scenario is supported
Is anyone able to help me correctly call a Wcf service from within an NServiceBus Saga\Handler?
Presently I am making a synchronous call from within a Handler.
However, IIRC, in a while ago on the NServiceBus documentation pages it recommended using a Saga but provided no further details.
My understanding is that a Saga is preferred as it can be persisted while the Wcf call is being processed and then resumed to receive the response.
(The only other thought is that a Saga is preferred as they are generally longer running than Handlers).
What I need help with is the most appropriate way to resume the Saga instance on the reply from the Wcf service.
Thanks
Mark
You actually wouldn't want the saga to call any external resource directly.
Instead, the saga would send a message to a handler and that handler would synchronously call WCF and then send a message back with the response.
If the call to WCF times out, the handler would do its automatic retry logic, or potentially the message might end up in an error queue.
The saga would then be able to deal with the logic of what to do if a response is not received within a certain period of time.
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 want to implement a WCF service that responds immediately to the caller, but queues up an asynchronous job to be handled later. What is the best way to go about doing this? I've read the MSDN article on how to implement an asynchronous service operation, but that solution seems to still require the task to finish before responding to the caller.
There are many ways to accomplish this depending what you want to do and what technologies you are using (e.g. Unless you are using silverlight, you may not need to have your app call the service asynchronously) The most straight forward way to achieve your goal would be to have your service method start up a thread to perform the bulk of the processing and return immediately.
Another would be to create some kind of request (e.g. Create an entry in a datastore of some kind) and return. Another process (e.g. A windows service, etc.) could then pick up the request and perform the processing.
Any WCF service can be made asynchronous -
One of the nice things about WCF is you can write a service synchronously. When you add a ServiceReference in the client, you have the option of generating asynchronous methods.
This will automatically make the service call asynchronous. The service will return when it's done, but the client will get two methods - BeginXXX and EndXXX, as well as XXXAsync + an XXXCompleted event, either of which allows for completely asynchronous operation.
I have a WCF Workflow Service (running on AppFabric) that accepts a Connect receive operation, and then move on to listen to a number of other operations.
When trying to break the workflow from my unit test, by invoking Connect twice, the service won't respond on my second request, but will wait until a timeout occurs.
I am expecting an error message such as this one:
How do I handle "Receive" calls being made out of order?
Operation 'AddQualification|{http://tempuri.org/}IZSalesFunnelService' on service instance with identifier '1984c927-402b-4fbb-acd4-edfe4f0d8fa4' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees
Note
The behaviour looks like in this question, but the current workflow does not use any delays.
I suspect you are still being bitten by the same issue as in the other question you are referring to. This is a bug in the workflow runtime scheduler.