As far as I understand if I click canCreateInstance, then for each request that comes to the service, there is created a new thread and that request is executed immediately.
If canCreateInstance is disabled, then the requests will be put in a queue and they will be processed one at a time.
Is this correct? I am implementing a queue with canCreateInstance disabled. Do you know anything against something like this? How Can I start the service with canCreateInstance disabled
Given a WorkflowServiceHost receives a message matching the contract and operation name for the initial receive activity
If CanCreateInstance is true then WorkflowServiceHost will create a new instance of the workflow and deliver the message to the receive activity.
If CanCreateInstance is false then the WorkflowServiceHost will throw an exception
There is no context attached to the incoming message for the service and the current operation is not marked with "CanCreateInstance = true". In order to communicate with this service check whether the incoming binding supports the context protocol and has a valid context initialized.
The first receive activity in the workflow should always have CanCreateInstance = true otherwise the workflow cannot activate.
The reason this property exists is so we can have one Receive activity that works for both activating receives and continuing receives.
Related
Setting up a CMS consumer with a listener involves two separate calls: first, acquiring a consumer:
cms::MessageConsumer* cms::Session::createConsumer( const cms::Destination* );
and then, setting a listener on the consumer:
void cms::MessageConsumer::setMessageListener( cms::MessageListener* );
Could messages be lost if the implementation subscribes to the destination (and receives messages from the broker/router) before the listener is activated? Or are such messages queued internally and delivered to the listener upon activation?
Why isn't there an API call to create the consumer with a listener as a construction argument? (Is it because the JMS spec doesn't have it?)
(Addendum: this is probably a flaw in the API itself. A more logical order would be to instantiate a consumer from a session, and have a cms::Consumer::subscribe( cms::Destination*, cms::MessageListener* ) method in the API.)
I don't think the API is flawed necessarily. Obviously it could have been designed a different way, but I believe the solution to your alleged problem comes from the start method on the Connection object (inherited via Startable). The documentation for Connection states:
A CMS client typically creates a connection, one or more sessions, and a number of message producers and consumers. When a connection is created, it is in stopped mode. That means that no messages are being delivered.
It is typical to leave the connection in stopped mode until setup is complete (that is, until all message consumers have been created). At that point, the client calls the connection's start method, and messages begin arriving at the connection's consumers. This setup convention minimizes any client confusion that may result from asynchronous message delivery while the client is still in the process of setting itself up.
A connection can be started immediately, and the setup can be done afterwards. Clients that do this must be prepared to handle asynchronous message delivery while they are still in the process of setting up.
This is the same pattern that JMS follows.
In any case I don't think there's any risk of message loss regardless of when you invoke start(). If the consumer is using an auto-acknowledge mode then messages should only be automatically acknowledged once they are delivered synchronously via one of the receive methods or asynchronously through the listener's onMessage. To do otherwise would be a bug in my estimation. I've worked with JMS for the last 10 years on various implementations and I've never seen any kind of condition where messages were lost related to this.
If you want to add consumers after you've already invoked start() you could certainly call stop() first, but I don't see any problem with simply adding them on the fly.
I have a use case where I need my controller action to wait for the reception of a specific rabbitmq message so I can return the result to the client, this message would come from a separate worker performing a certain task.
My api project and the worker project are separated and rabbitmq bus is the only intermediary between them.
EDIT: This is the current Scenario:
Client sends request to the web api to ask for let's call it 'DATA'
The web api publishes a Message-A through rabbitmq
A separate service project handles the published Message-A, does some work, and publishes a new Message-B that contains the result of that work which we called 'DATA'
Here is the problem: My web api controller have to return the results contained in Message-B, so the controller action should wait for that message before returning to the client
You need to use a TaskCompletionSource<T>.
You need to subscribe to the reply messages and, if it's the reply you're waiting for, set the result of the task completion source.
Then await the task of the task completion source.
I need to implement a logic on Retry. Inbound endpoint pushes the messages to Rest (Outbound). If the REST is unavailable, I need to retry for 1 time and put it in the queue. But the second upcoming messages should not do any retry, it has to directly put the messages in to queue until the REST service is available.
Once the service is available, I need to pushes all the messages from QUEUE to REST Service (in ordering) via batch job.
Questions:
How do I know the service is unavailable for my second message? If I use until Successful, for every message it do retry and put in queue. Plm is 2nd message shouldn't do retry.
For batch, I thought of using poll, but how to tell to poll, when the service becomes available to begin the batch process. (bcz,Poll is more of with configuring timings to run batch)?
Other ticky confuses me is - Here ordering has to be preserved. once the service is available. Queue messages ( i,e Batch) has to move first to REST Services then with real time. I doubt whether Is it applicable.
It will be very helpful for the quick response to implement the logic.
Using Mule: 3.5.1
I could try something like below: using flow controls
process a message; if exception or bad response code, set a variable/property like serviceAvailable=false.
subsequent message processing will first check the property serviceAvailable to process the messages. if property is false, en-queue the messages to a DB table with status=new/unprocessed
create a flow/scheduler to process the messages from DB sequentially, but it will not check the property serviceAvailable and call the rest service.
If service throws exception it will not store the messages in db again but if processes successfully change the property serviceAvailable=true and de-queue the messages or change the status. Add another property and set it to true if there are more messages in db table like moreDBMsg=true.
New messages should not be processed/consumed until moreDBMsg=false
once moreDBMsg=false and serviceAvailable=true start processing the messages from queue.
For the timeout I would still look at the response code and catch time-outs to determine if the call was successful or requires a retry. Practically you normally do multi threading anyway, so you have multiple calls in parallel anyway. Or simply one call starts before the other ends.
That is just quite normal.
But you can simply retry calls in a queue that time out. And after x amounts of time-outs you "skip" or defer the retry.
But all of this has been done using actual Mule flow components like either:
MEL http://www.mulesoft.org/documentation/display/current/Mule+Expression+Language+Reference
Or flow controls: http://www.mulesoft.org/documentation/display/current/Choice+Flow+Control+Reference
Or for example you reference a Spring Bean and do it in native Java code.
One possibility for the queue would be to persist it in a database. Mule has database connector that has a "poll" feature, see: http://www.mulesoft.org/documentation/display/current/JDBC+Transport+Reference#JDBCTransportReference-PollingTransport
I have a win forms client that accesses a wcf service for a long running operation. The service exposes subscribe and unsubscribe methods. When a client calls the subscribe method, service generates new guid for it and gets the current callback context, saves this guid and callback context in a client Dictionary and returns the Guid. On user request, client call service with this guid to start the long operation. Once the service finishes the operation it gives a callback to the client. the client then retrieves the processed data from the service.
The error I get sometimes when doing a callback is
The operation 'OnServiceCallback' could not be completed because the sessionful channel timed out waiting to receive a message. To increase the timeout, either set the receiveTimeout property on the binding in your configuration file, or set the ReceiveTimeout property on the Binding directly.
The part that I am not able to understand is that this happens very inconsistently. Most of the times it happens after the client and the service have been running for some time.
I am a beginner in wcf service and welcome any suggestions to solve this error.
Binding has property called receiveTimeout. This property is by default set to 10 minutes. It defines how long does the service instance wait for next request before it is terminated. So if there is no activity between client and service within 10 minutes your service instance is closed and client can't use it any more. In duplex service it can be even more complicated because there are services on both sides. You will probably need to configure receiveTimeout on both ends.
I was able to figure the answer to the error by doing some good old trial and error. The callback was failing because the OperationContext.Current object that I was trying to use was null. This was because I was trying to access the OperationContext.Current object on a thread which was different from the service thread. So to solve that I am now accessing the OperationContext.Current object in the service thread and then passing the callbackContext as a parameter to the external processing logic which actually needs to use it.
NServiceBus provides a timeout mechanism. From nservicebus.com:
The RequestTimeout method on the base
class tells NServiceBus to send a
message to another endpoint which will
durably keep time for us ... There's a
process that comes with NServiceBus
called the Timeout Manager which
provides a basic implementation of
this functionality.
When time is up, the Timeout Manager
sends a message back to the saga
causing its Timeout method to be
called with the same state object
originally passed.
As I see it there is a possibility that the timeout is triggered even though the message has been delivered to the receiver (the reply got stuck somewhere for example).
How do I design my application in such a way that my application will behave correctly regardless if the message made it to the receiver or not.
If the Client sends a message to the Server and then requests a Timeout, the state of the request will be stored. If the Timeout message is received by the Client prior to the reply from the Server then you can compare the state returned by the Timeout to the current state and see that the Server has not replied and decide what to do. If the request is no longer valid, you might ignore the reply. If that is the case, you may want to look at the "TimeToBeReceived" attribute for the Server message. It will throw away messages it can't receive in the designated time.