Develop Reference

WCF Call, slow on Internal Funcions, but quick when calling functions directly

I have a self hosted WCF service, using basic http binding. I am finding that calls made to the wcf service, accessing functions exposed by the WCF, take much much longer to complete (internally) than when using the functions directly (from the wcf service).
So to clarify, I am not talking about taking longer "over" the wcf call. Once the internal exposed functions behind the WCF are run, they, in their own processing, take much longer to do their work and return something back to the wcf service, for sending to the client, than when I access those same functions directly from a form in my hosted wcf app.
I have added extensive logging, logging start and stop time for all functions, and it seems to be consistent. The same functions, when activated through WCF, seems as if they are run at a much lower "priority" than when calling them bypassing the WCF interface.
Taking this into account, I am pretty sure this started sticking its head out after I decorated my main wcf class with the following, due to my UI thread locking up:
<ServiceBehavior(useSynchronizationContext:=False)>
Are the threads created due to the above decoration, running at a lower priority?
Direct Call from form in WCF hosted App: 5 seconds
Call Through WCF Interface: 20-30 seconds (Excluding time over the wire)
The physical return from the WCF service itself, once the internal functions are complete, is quite quick.
I do quite a lot of "work" once the internal functions are reached.
Any ideas?
Thanks
Basic WCF Service Code:
Dim myservicehost As ServiceHost
Dim myServiceAddress As New Uri("http://" & LocalIpAddress & ":" & tcp_port & "/" & servicename)
myservicehost = New ServiceHost(GetType(myWCFFunctions), myServiceAddress)
' Enable metadata publishing.
Dim smb As New ServiceMetadataBehavior()
smb.HttpGetEnabled = True
smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15
myservicehost.Description.Behaviors.Add(smb)
myservicehost.Open()

I could not get this solved, and reverted back to my previous implementation.

WCF duplex: calling callback outside class of WCF-service

I develop WCF-service with duplex mode and use nettcpbinding. I use .NET 4.5. I have only one client and only one server and there is a lot of logic between its. The client always the first begins communication with the server. I want that server can call client functions outside WCF-service class. I try to use duplex mode for this purpose.
This is my WCF-service:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single, InstanceContextMode = InstanceContextMode.Single)]
public class Service : IService
{
...
public IServiceCallback Callback
{
get
{
return OperationContext.Current.GetCallbackChannel<IServiceCallback>();
}
}
}
I have no problem when I call my callback within OperationContract functions of my service:
Callback.foo();
But when I try to call it outside class Service for example:
service = new Service();
service.Callback.foo();
I got NullReferenceException of OperationContext.Current. I found a lot of information about the similar problems on the SO and other resources but it can't help to decide my problem.
Are there any solutions of my issue or may be workarounds for calling of callback? At the moment I plan to create one more WCF-service for my purpose but I feel that this is bad solution. Thanks for attention.

OperationContext.Current has a meaning only when it runs from the same thread that handles the current client request. You did not specify where exactly you calls this from.

WebServiceHost: Blocking call in a webservice method blocks whole service

I have a WCF webservice using the WebServiceHost class.
new WebServiceHost(typeof(MyServiceClass));
If I use a blocking call like Thread.Sleep (just an example) in one of my webservice methods and i call this method the whole service is not usable while the blocking call is active.
Is that normal behaviour or is there an error somewhere in my configuration or usage?

What's the InstanceContextMode and ConcurrencyMode settings on your service? If it's set to Single then there's only one instance of your service and all the calls are queued so if you put the service thread to sleep it will block all subsequent calls.
For example:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
ConcurrencyMode = ConcurrencyMode.Single)]
public class MyService : IMyService
{
}

Ok, I got it. If you start the service in a windows forms GUI thread you can add
UseSynchronizationContext = false
to the ServiceBehavior and the requests get handled in parallel. :)

WCF service instance will not close despite only calling oneway method

I have a WCF service running inside a windows service on a remote machine.
In the WCF service's contract, I have a method that takes a long time to run set up as
[OperationContract(IsOneWay = true)]
void Update(myClass[] stuff);
Everything works fine, the method gets called, I can see what it needs to do start getting done.
The problem is when I go to close the instance of the WCF service in my code, it times out and I get:
The socket connection was aborted.
This could be caused by an error
processing your message or a receive
timeout being exceeded by the remote
host, or an underlying network
resource issue. Local socket timeout
was '00:02:00'.
I thought the one way contract allowed me to fire and move on. Is there something I am missing? If not are there workarounds for this?

The ServiceContract attribute on your service's interface definition defaults the SessionMode property to SessionMode.Allowed, i.e.,
[ServiceContract(SessionMode = SessionMode.Allowed)]
public interface IMyContract
{
[OperationContract(IsOneWay = true)]
void Update(myClass[] stuff);
}
According to Juval Lowy's Programming WCF Services,
...when the SessionMode property is
configured with SessionMode.Allowed,
it merely allows transport sessions,
but does not enforce it. The exact
resulting behavior is a product of the
service configuration and the binding
used.
Thus, if you are using the WSHttpBinding with security or reliable messaging, the NetTcpBinding, or the NetNamedPipeBinding, then the service will behave as a per-session service. This simply means that as long as the client proxy has not been closed, a session will still be in place between the service and the client. By closing the client proxy as suggested by Shiraz should fix this.
Juval's book also says this with regard to one-way operations:
If the number queued messages has
exceeded the queue's capacity, then
the client will block, even when
issuing a one-way call. However, one
the call is queued, the client is
unblocked and can continue executing,
while the service processes the
operation in the background.
So while one-way operations do allow for fire-and-forget operation, you can still run into cases where your client may block.

Your "Update" is a method on the service.
When you open the wcf client, a connection to the service remains open until you call Close (or Abort).
You are probably not calling close, and it is therefore remaining open until it timesout.

WCF: Callback is not asynchronous

I'm trying to program a client server based on the callback infrastructure provided by WCF but it isn't working asynchronously.
My client connects to the server calling a login method, where I save the clients callback channel by doing
MyCallback callback =
OperationContext.Current.GetCallbackChannel<MyNamespace.MyCallback>()
After that the server does some processing and uses the callback object to communicate with the client.
All this works, the problem resides on the fact that even though I've set the method in the OperationContract as IsOneWay=true, the server still hangs when doing the call to the client.
I've tested this by launching the server for debug in the Visual Studio, detaching it, launching the client, calling the above mentioned login method, putting a break point in the implemented callback method of the client, and making the server send a response to the client. The server stops doing what it's supposed to do, waiting for the response of the client.
Any help is appreciated.

The trick is, to call the callback asynchronously from the server. Look at this:
[OperationContract(IsOneWay = true, AsyncPattern = true)]
IAsyncResult BeginOnMessageReceived(LiveDataMessage message, AsyncCallback acb, object state);
void EndOnMessageReceived(IAsyncResult iar);

I think the sollution to your problem is to properly set the 'ConcurecyMode' and 'Instance ContextMode' attributes for your service. To do that you must decorate your service declaration with those attributes as shown in the exemple below:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)]
public class SubscriberService: ISubscriberServiceContract
{...}
InstanceContextMode.Single builds your service as a Singleton object so there is only one instance of your service running for all clients;
ConcurencyMode.Reentrant or ConcurencyMode.Multiple enables multithreaded work for the service instance. For 'Multiple' you must take care of thread syncronization in your service.

Did you try to set
[CallbackBehavior(UseSynchronizationContext = false)]
on the client side object implementing the callback interface ?