January 11, 2005 at 9:56 am
Anyone seen this yet? When I browse to the report manager url (http://myserver/Reports$YUKONBETA2) I get one of the two following error messages:
An unexpected error occurred on a receive or
The request failed with HTTP status 503: Service Unavailable.
The actual page starts to display but the errors are returned in the bottom frame. The strange thing is that the Report Server IS working, I have reports compiled and ready to go. When I browse to http://myserver/ReportServer$YUKONBETA2, I can get to the reports and run them. The Report Manager doesn't want to play nice with the Report Server.
The reason the $YUKONBETA2 is present in the URLs is because I have SQL 2000 and 2005 installed side-by-side. The 2005 installation program created those URLs after I named my 2005 instance YUKONBETA2.
Any ideas?
January 12, 2005 at 5:47 am
Did you check to see if the Report Service is running. If it is not I would check who the service is running as and make sure they have the appropriate rights.
January 13, 2005 at 8:19 pm
We have been getting those kind of errors, not in Reports Manager, but when calling the ReportServer web service programatically. In my experience, the problem occurs frequently whenever there are multiple concurrent connections to the ReportServer web service. I have had an open support case with Microsoft since November, which today they transferred to an "escalation engineer". If they develop a hotfix to solve this problem, I will post a notice here.
January 19, 2005 at 6:34 am
Just an update to my post...
I've been working with some knowledgable people and I haven't been able to find a resolution to my problem. Two things that may be causing it, 1) I have SQL 2005 installed side-by-side with SQL 2000, 2) Reporting Services was installed after the initial SQL 2005 install. According to my sources, Reporting Services can be finicky about pathing.
If I get this resolved I'll post here.
January 23, 2005 at 1:10 am
Well, we don't have SQL Server 2005 installed. So that may or may not have anything to do with it. But I would suggest that you test Reporting Services on a machine without any beta software installed.
May 23, 2005 at 12:42 pm
We finally solved our problem (see details below). In our case the error occurred only a multi-processor report server and only when there were multiple concurrent calls to the Report Server web service. The culprit was actually in a custom assembly method called in some of our reports.
Finally this case is closed! It only took us nearly six months to solve it. Yikes! I must give Microsoft support credit though for sticking with it until the problem was solved.
So, it turns out that the intermittent failure of the Reporting Services web service was not a problem with Reporting Services at all. It was actually a problem with dynamically generated images (i.e., barcode and watermark images) in our work order reports.
Apparently, the problem was a threading issue with the System.Drawing.Text.PrivateFontCollection class, which is really an array of FontFamily objects that wraps classes in an unmanaged GDI+ DLL. The PrivateFontCollection class’s constructor contains a critical section for thread synchronization that apparently is very prone to deadlocks when called from multiple threads. So the solution is to either avoid the PrivateFontCollection or instantiate it as infrequently as possible. In our case, we can instantiate it when the first report is rendered after the Report Server service starts instead of instantiating it every time we render an image in a report. The object is then stored in a static member variable and is available for subsequent report/image renderings. Now that I know the dangers of using the PrivateFontCollection class, in the future I would try to avoid it by using the InstalledFontCollection class or just using individual fonts instead of a FontCollection.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply