I have implemented Sync framework in WCF service.
Code:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)] in my service contract class
Having error The call to BeginSession() in RelationalSyncProvider is not valid. A session is already in progress sorry for late
on
SyncOperationStatistics stats = orchestrator.Synchronize();
Please guide me to resolve this issue.
Thank you.
Replicated this issue server side by having multiple clients connect concurrently.
Exception was server side at SqlSyncProvider.BeginSession(). In Sync 2.1.
I solved this by making sure the SqlSyncProvider for the server was per client instead of static across all client connections.
Since I was replicating this via unit tests I also had this issue when client proxy reference was static, switched that to instance as well.
Related
i have web service(cxf integated with spring(jax-ws)) project which it was deployed on Weblogic(12.1.1).
Another project as client was deployed same application server in another machine.
My problem is that at least 23 second of time for sending info from server to client.(this time is more long),but this time very fast when request is called by Soap Ui.
how can i config weblogic for improvement this problem.
I was searching a lot finally i found solution of my problem.
JaxWSProxyFactoryBean is object of cxf client to communicate with cxf server.
This Object have a property is named Bus,if this property not set in config cxf client,performance wont be better
Consider following scenario during development -
We change WCF service contracts very frequently.
There is a web application consuming these services.
We do update, service reference frequently in the web application.
But at times when we forget to do this, we have to debug our whole web application, to finally find out that, the service contract has changed.
Can we detect outdated proxy at runtime before invoking the service.
The best practice is to version your service to allow the client to connect with the interface its familiar with. Usually you keep one or two versions older online and add any breaking changes as an up-rev to the service. (e.g. /myservice/2012/01 then /myservice/2012/06). Then as new versions are created you can deprecate previous versions.
Second practice would be to implement a GetVersion() (or similar) method you can call and use for testing purposes. Make an initial call to the service and see what it's running then test against a locally stored version number and see if a conflict exists.
For more detail on this, there's a good article by Yoav Helfman that goes over handling version changes and updates.
I have posted about this kind of thing before.
Essentially one way to manage this situation is to require your service consumers to declare what version of the service interface they are expecting with each request.
Then expose a fault contract on your service of a type which will allow you to identify that a service version mismatch has occurred. This will mean that consumers can catch and then handle this specific problem accordingly.
I have always followed the guidance of try/Close/catch/Abort when it comes to a WCF proxy. I am facing a code base now that creates proxies in MVC controllers and just lets them go out of scope. I'm arguing the case that we need to edit the code base to use try/Close/catch/Abort but there is resistance.
Does anyone know a metric (e.g. perfmon) I can capture to illustrate the problem/benefit. Or a definitive reference that spells out the problem/benefit no one can dispute?
You can create a sample application to mimic the problem. Though I haven't tried you can try this,
Create a simple service and limit the maxConcurrentCalls and maxConcurrentSessions to 5.
Create a client application and in that, call the service method without closing the connection.
Fire up 6 or more clients
See what happens when you open a new connection from a client. Probably the client will wait for certain time and you get some exception.
If the client don't close the connection properly, the connection will still remain open in the service so what happens if 1000s of client connected to the service at a time and leave their connections open? The service has a limitation that it could server 'n' connections at a time and because of that the service can't handle any new requests from clients and that's why closing connections are very important.
I think you are aware about the using problem in WCF service. In my applications I close the WCF connections using an extension method as said in this thread.
Have you tried a simple 'netstat -N' from the command prompt both on server and client? Yoy are likely to see a lot of waiting/pending connections which might exhaust your server resources for no reason.
This may be a shot in the dark (I don't know much about the internals of WCF), but here goes...
I'm currently working with a legacy application at a client site and we're experiencing a persistent issue with a WCF service. The application is using the Microsoft Sync Framework 2.0 and syncing through the aforementioned service. The server-side implementation of the service has a lot of custom code in various states of "a mess."
Anyway, we're seeing an error on the client application most of the time and the pattern we're narrowing down centers around different users using the application on the same machine hitting the same service. It seems that the service and the client are getting out of sync in some way on an authentication level.
The error is discussed in an article here, and we're currently investigating the approach of switching from message layer security to transport layer security, which will hopefully solve the problem. However, we may be able to solve it in a less invasive manner if this question makes sense.
In the linked article, one of the suggestions was to forcibly terminate the connection if the specific exception is caught, try again, and if it fails again it wasn't because of this particular theory. Sounds good, and easy to implement. However, I find myself unable to say with confidence if the connection is being properly terminated.
The service operates through a custom interface, which is implemented on the server-side. The only thing that interface can do to end the connection is call EndSession() on the proxy itself, which calls EndSession() on the server which is a custom method.
So...
From a WCF service method, is there a way to properly and gracefully terminate the connection with the client in a way the client will like?
That is, in this custom EndSession() is there some last step I can take to cause the server to completely forget that this connection was open? Because it seems like when another user on the same machine tries to hit the service within the application, that's when it fails with the error in the linked article.
The idea is that, at the client side of things, code which calls EndSession() is followed by nulling out the proxy object, then a factory method is called to supply another one the next time it's needed. So I wonder if something additional needs to happen on the server side (and does by default in WCF were it not for all this custom implementation code) to terminate the connection on that end?
Like I said, a shot in the dark. But maybe in answers/discussions here I can at least further diagnose the problem, so any help is much appreciated. Thanks.
Unfortunately there are only really three ways in which a session can terminated
The client closes the proxy
The service's receiveTimeout is exceeded
before the client sends another
request
the service throws a
non-fault exception which will fault
the channel and so terminate the
session
if you don't want the client involved then you only have 2 and 3 neither of which end well for the client - they will get an exception in both situation on the next attempt to talk to the service.
You could use Duplex messaging and get the service to notify the client that its requires session termination - the client then gets an opportunity to close down the proxy gracefully but this is a cooperative strategy
SoapFaultException when invoking Myservice, saying “contract and binding mismatch between sender and receiver"?
above is my problem,
i have created WCF services and tested in Local(.net it is working fine.so hosted in Remote server. my client is using Java, when ever he is accessing the Wcf services ,he is getting error like" SoapFaultException saying “contract and binding mismatch between sender and receiver"
help me.
Thanks in advance
This sometimes happens if you are trying to call an old instance of your service with a proxy created for a new instance of your service. Or vice-versa.
If you are 100% sure that the service you are calling has the new method installed and running, then you should be able to diagnose this further by turning on tracing on the service.
Here is what I suggest, which I also suggested in another post:
Enable tracing on the service side and the client side, generate tracing logs, and analyze with SvcTraceViewer. To do this, follow the instructions at this MSDN article on using the service trace viewer.
Turn on debug exceptions. This is done by turning in includeExceptionDetailInFaults, which you can do by following the instructions here.
Use Fiddler to monitor the wire traffic on both the client side and the service side.
Generally, once you do this, you should plenty of more info on what's going funky at the service side and can diagnose the issue pretty quickly. Try it, and please report back! :)