I have unusual problem that I can't figure out.
I have a sharp architecture project that I am developing, and using WCF services which I host using IIS ASP.NET.
When the services were hosted on my machine everything worked out fine. Now I have hosted the services on a different server and running the client from my machine. once I have done that the SaveOrUpdate() methods seems to be not working. No errors are being thrown out and it returns a successfull operation, but the data is not persisted to the db. The issue I can't figure out is why was this working when the services were hosted locall and now not working when they are hosted some where else.
I think I ran into a similar issue before, basically the transaction is never committed. try manually beginning and committing your transactions.
Related
I have a Problem which confuses me a little bit, resp. where I don't have any idea about what it could be.
The System I'm using is Windows Vista, IIS 7.0, VS2008, Windows Software Factory, Entity Framework, WCF. The Binding for all Webservices is wshttpbinding.
I'm using a Webservice hosted in IIS. This Webservice uses/calls another Webservice (also installed in the IIS). If I use a client calling the first Webservice (which calls the second Webservice) it works fine for about 4-10 Times. And then (it is repeatable to get this Problem, but sometimes it happens after 4, sometimes after 10 Time, but it always will happen), the Service and the IIS gets stuck.
Stuck means, that this Webservice isn't callable anymore and generates an timeout after 1 minute.
Even increasing Timeout doesn't change anything.
If i try to restart the IIS I get an timeout error (and this is really confusing me. It seems that the Webservice has "crashed" somehow and blocks the Restart of the IIS). So the IIS is also "stuck" (it is not really stuck, but I can't restart it). Only if I kill the w3wp.exe IIS is restartable and the Webservice will work again (until i again call this service several times).
The logfiles (i'm no expert in things like logging or where to find/enable such logs, so to say : i'm a newbie) like http-logging, Event Viewer or WCF-Message Logging don't show any hints upon the source of the problem.
I don't have this problem when I'm using a Webservice which doesn't call another Service.
Calling a Webservice is done by Service Reference (I'm using no Proxy-Classes), but I think this should be no Problem.
I have no idea of what is happening, nor how to solve this Problem.
Regards
Rene
Edit. : I hope my posting is more readable now :-)
insert System.Diagnostics.Debugger.Break() into your web service code. When that point is reached, you will be able to step through the service logic. This may help you diagnose the cause of the deadlock.
Another alternative is to turn on WCF Tracing, and diagnose that way.
I am attempting to reproduce a server farm in my test environment, in order to try something out for an application that I am busy designing.
I have two web servers, running IIS 6.0 and 7.0 respectively, each hosting a workflow service with exactly the same dlls. They share a persistence database.
When ServerA saves the workflow to the persistence store, on a subsequent request ServerB is happy to load the workflow instance and do some work on it. Once ServerB has saved the workflow, ServerA gets a serialization exception when attempting to perform a further call on the workflow. I get the same behaviour if I use a different server as ServerB.
And I can fix the problem by using two different servers and leaving ServerA out of the equation.
My question though is: How can I debug exactly why ServerA will not load workflows saved by other machines?
Update - I did try with two IIS 6.0 servers, same OS and same strongly names assemblies - and had the exact same issue
OK, I figured it out.
ServerA had a hotfix installed for .NET, which meant that the actual binary signature of one of the classes being serialized was different.
By pure chance it can be deserialised one way and not the other.
I loaded the hotfix on all of the servers, and now the serialization works correctly.
I'm trying to cache some application data that only needs to be instantiated when the application starts. I've tried using HttpRuntime.Cache, creating a static object that is instantiated only when the service starts, and I've tried making the service singleton and using global variables. Every time a new request hits the service I loose state... I could create the WCF service as a windows service I suppose, but I'd love to figure out what's happening here... I see that only one IIS worker process is spawning, but I'm guessing it's unloading and re-loading the service every time.
Am I missing some WCF configuration or possibly not setting it up right in IIS? It's running as a normal 2.0 website within IIS.
This my first post here, if someone can tell me how to post my app.config XML I will... I think stackoverflow is trying to parse it as HTML, it doesn't show up.
Thank you!
Tim
We use enterprise library caching with WCF services, works for us:
http://msdn.microsoft.com/en-us/library/dd203099.aspx
Edit
This answer is a bit old we have now stopped using Enterprise Library Caching, we use app fabric instead, see: http://msdn.microsoft.com/en-us/windowsserver/ee695849
I have a WCF service that does some document conversions and returns the document to the caller. When developing locally on my local dev server, the service is hosted on ASP.NET Development server, a console application invokes the operation and executes within seconds.
When I host the service in IIS via a .svc file, two of the documents work correctly, the third one bombs out, it begins to construct the word document using the OpenXml Sdk, but then just dies. I think this has something to do with IIS, but I cannot put my finger on it.
There are a total of three types of documents I generate. In a nutshell this is how it works
SQL 2005 DB/IBM DB2 -> WCF Service written by other developer to expose data. This service only has one endpoint using basicHttpBinding
My Service invokes his service, gets the relevant data, uses the Open Xml Sdk to generate a Microsoft Word Document, saves it on a server and returns the path to the user.
The word documents are no bigger than 100KB.
I am also using basicHttpBinding although I have tried wsHttpBinding with the same results.
What is amazing is how fast it is locally, and even more that two of the documents generate just fine, its the third document type that refuses to work.
To the error message:
An error occured while receiving the HTTP Response to http://myservername.mydomain.inc/MyService/Service.Svc. This could be due to the service endpoint binding not using the HTTP Protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the server shutting down). See server logs for more details.
I have spent the last 2 days trying to figure out what is going on, I have tried everything, including changing the maxReceivedMessageSize, maxBufferSize, maxBufferPoolSize, etc etc to large values, I even included:
<httpRuntime maxRequestLength="2097151" executionTimeout="120"/>
To see maybe if IIS was choking because of that.
Programatically the service does nothing special, it just constructs the word documents from the data using the Open Xml Sdk and like I said, locally all 3 documents work when invoked via a console app running locally on the asp.net dev server, i.e. http://localhost:3332/myService.svc
When I host it on IIS and I try to get a Windows Forms application to invoke it, I get the error.
I know you will ask for logs, so yes I have logging enabled on my Host.
And there is no error in the logs, I am logging everything.
Basically I invoke two service operations written by another developer.
MyOperation calls -> HisOperation1 and then HisOperation2, both of those calls give me complex types. I am going to look at his code tomorrow, because he is using LINQ2SQL and there may be some funny business going on there. He is using a variety of collections etc, but the fact that I can run the exact same document, lets call it "Document 3" within seconds when the service is being hosted locally on ASP WebDev Server is what is most odd, why would it run on scaled down Cassini and blow up on IIS?
From the log it seems, after calling HisOperation1 and HisOperation2 the service just goes into la-la land dies, there is a application pool (w3wp.exe) error in the Windows Event Log.
Faulting application w3wp.exe, version 6.0.3790.1830, stamp 42435be1, faulting module kernel32.dll, version 5.2.3790.3311, stamp 49c5225e, debug? 0, fault address 0x00015dfa.
It's classified as .NET 2.0 Runtime error.
Any help is appreciated, the lack of sleep is getting to me.
Help me Obi-Wan Kenobi, you're my only hope.
I had this message appearing:
An error occured while receiving the HTTP Response to http://myservername.mydomain.inc/MyService/Service.Svc. This could be due to the service endpoint binding not using the HTTP Protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the server shutting down). See server logs for more details.
And the problem was that the object that I was trying to transfer was not [Serializable]. The object I was trying to transfer was DataTable.
I believe word documents you were trying to transfer are also non serializable so that might be the problem.
Yes, we'd want logs, or at least some idea of what you're logging. I assume you have both message and transport logging on at the WCF level.
One thing to look at is permissions. When you run under Cassini the web server is running as the currently logged in user. This hides any SQL or CAS permission problems (as, lets be honest, your account is usually a local administrator). As soon as you publish to IIS you are now running under the application pool user, which is, by default, a lot more limited.
Try turning on IIS debug dumps and following the steps in KB919789
Fyi, I changed IIS 6 to work in IIS 5.0 Isolation mode and everything works. Odd.
I had the same error when using an IEnumerable<T> DataMember in my WCF service. Turned out that in some cases I was returning an IQueryable<T> as an IEnumerable<T>, so all I had to do was add .ToList<T>() to my LINQ statements.
I changed the IEnumerable<T> to IList<T> to prevent making the same mistake again.
I have a WCF application with a couple thousand clients connecting to a pair of services running under IIS. What I've noticed is that some of these clients get into a hung state, and I'm trying to reproduce this.
When this problem was first noticed, I had not modified the throttling configuration and the services were set to ConcurrencyMode.Single. One thing I noticed was that an IISReset on the server caused many clients to hang. Yet pulling this same stunt on the client running against IIS on my local machine doesn't seem to cause the problem.
I caught this only once in the wild, but didn't have debugging enabled at the time. The symptom I witnessed was that the client appeared to be trying to open a connection to the web server, but did not succeed. While monitoring with Fiddler, I saw no attempt to reach the service endpoint. Obviously that makes me suspect the client proxy.
I have a very solid hunch as to what's happening -- namely I've been using "Close()" instead of "Abort()" when the service throws an exception, which I believe is causing the channels to become corrupted. But considering the effort to get a new version out there, I need to reproduce this problem by causing a client on my own machine to hang before I can start making changes to the code.
Where should I start?
Thanks in advance,
roufamatic
Have you got any logging turned on? This could help in diagnosing the problem. It can be done completely in config, so no need to build a new version. Use the Service Configuration Editor tool to set it all up. The Visual Studio 2008 Training Kit has a good tutorial on how to use logging and the log viewer.
I suppose this was too vague a question though I was mostly curious what people might suggest. As it turns out there was a nontrivial difference between my workstation and a production environment that, once resolved, allowed me to see the problem. In this case, somehow using Fiddler to watch the traffic actually prevented the error from occurring! Now to ask another question.