ansaurus

Question

Choosing correct connection properties for long running WCF applications

Answer 1

+4 A:

Just a wild thought: since your clients seem to be sending messages over a long period of times (days even), but don't seem to send them very frequently - could you maybe rearchitect your app to use something like a message queue instead of callback contracts?

Queues are a great way to decouple two systems and reduce potential for timeouts etc.

In a queue-based scenario, your clients would drop off a message into a queue (e.g. MSMQ which ships with every copy of Windows Server) and your service will listen on that incoming queue for messages. The service will grab the messages, process them, and typically put some kind of a response message back a second queue (to which the clients then listen).

The main benefits here are:

you don't need the rather brittle and complicated call-back contract setup
your systems are decoupled and will continue to work even if the connection between them is broken for a few seconds, minutes, hours
your service can respond to incoming messages and send back more "targetted" responses, e.g. certain clients can listen on the "normal" response queue, others on a "priority" response queue etc. - the system just gives you more flexibility IMO

See more resources:

and check out things like

NServiceBus

and other systems (MassTransit et. al.) which favor queued communications to provide seriously scalable, reliable messaging between systems.

marc_s 2010-03-06 14:38:58

Hi Marc, great thanks for your answer. Unfortunately the project is 98% finished and I have only 2 weeks left to implement the missing stuff. Throwing the current architecture away and going with another approach doesn't sound right at this point in time.Unfortunately I have to solve this problem with WCF for now and then probably redesign the architecture in version 2.0.I hope you guys can give me the answer to my problem. Initially I thought that WCF was exactly designed for this kind of stuff....

klausliebknecht 2010-03-06 15:37:07

Yes, of course - WCF is great and very flexible. It supports MSMQ messaging, too! The callback contract stuff is a bit "flaky" at times, not necessarily WCF's fault, it's just tricky to do.

marc_s 2010-03-06 16:40:10

Answer 2

A:

I encountered one thing:

In one service contract, I change something and notify all connected clients. It usually works fine, at least in my tests. But last "crash" or "freeze" I stepped through the log and saw that the latest function was where I use callback contracts to notify the clients.

What I want to do there: I save something to the database and at the end I notify all connected clients of the change. I think that the list of connected clients is not current anymore and it runs into a timeout at this step.

Now the question is how to avoid these timeouts.

Should I use threading in the service? I think the threads will be killed as soon as the service call ends, am I right here?
I could implement a static queue function which does all the callback-notification (this is something Marc_S suggested)
Is there a way to reliably detect connection drops inside the server?

Great thanks in advance

klausliebknecht 2010-03-06 20:28:30

Answer 3

A:

Ok, problem is solved.

The problem occurred whenever one client died unexpectedly withouth logging out. So whenever a client called a method from the service which itself wanted to broadcast a message to all connected clients, it ran into a timeout which in turn blocked the client. So wrapping all callbacks up into a delegate function helped to solve the problem.

Here is how I did it:

public enum CallbackType
{
    callbackfunc1,
    callbackfunc2,
    callbackfunc3
};
public class CallbackEventArgs : EventArgs
{
    public ISVCCallback callback;
    public CallbackType type;
    public string s1;
    public string s2;
    public string s3;
    public List<string> ls1;
}

// Declare delegate
public delegate void SVCEventHandler(object sender, CallbackEventArgs e);

... now in the service definition

public string Login(...)
{
    Client cl = new Client(MyCallbackHandler);
    ....

    CallbackEventArgs ce = new CallbackEventArgs();
    ce.callback = cl.CallbackChannel;
    ce.type = CallbackType.callbackfunc1;
    ce.s1 = "Parameter A";
    ce.s2 = "Parameter B";
    cl.MyCallBackHandler.BeginInvoke(this, ce, new AsyncCallback(EndAsync), null);
}

private void MyCallbackHandler(object sender,  CallbackEventArgs e)
    {
        try
        {
            switch (e.type)
            {
                 case CallbackType.callbackfunc1:
                       e.callback.callbackfunc1(e.s1, e.s2);
                       break;
                 default:
                       throw new MissingFieldException(e.type);
            }
    }
    catch(TimeoutException tex){
        // Remove current client, channel timed out
    }
    catch(Exception ex){
        // Do something
    }
}

private void EndAsync(IAsyncResult iar)
    {
        SVCEventHandler d = null;
        try
        {
            System.Runtime.Remoting.Messaging.AsyncResult asres = (System.Runtime.Remoting.Messaging.AsyncResult)iar;
            d = ((SVCEventHandler)asres.AsyncDelegate);
            d.EndInvoke(ar);
        }
        catch(Exception ex)
        {
            // Do something
        }
    }

Thanks!!

klausliebknecht 2010-03-06 23:46:10

ansaurus

tags:

views:

answers:

Choosing correct connection properties for long running WCF applications

related questions