"ContextSwitchDeadlock was detected" exception

[Michael]

Hi

I received this exception while I've tried to export to PDF 12 000+ records using Rad ReportViewer; project is made in WCF, version 5.1.11.713, runtime version: v2.0.50727 and I'm not using special code to display/export report/data.

report.DataSource = items;
report.ReportParameters["paramHideDetails"].Value = chkHideDetails.IsChecked;

 report.ReportParameters["paramHideTotals"].Value = chkHideTotals.IsChecked;

report.ReportParameters["paramHideTargetWeight"].Value = chkHideTargetWeight.IsChecked;

report.ReportParameters["paramFilterCriteria"].Value = paramFilterCriteria;

 rvMain.Report = report;

When displaying report no exception raised, only when exporting!
What I discovered is that ReportViewer requires some time to process if this helps...

Exception description:
ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x458150 to COM context 0x458378 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Thanks
Dan

[Michael]

Hi again

Other aspects:
1. export menu from ReportViewer toolbar is not disappearing after selecting the option and I must close window (which contains ReportViewer) to make it disappear.Is this a bug or I'm doing something wrong?
2. exporting 1200+ records from a report (which contains a chart) take a lot of time; I've tested how much time takes to select records (data source) & other operations and these are under 2 secs, but processing export takes minutes. Why is that?

Remember, it's a WPF project.
Thanks
Dan

[Peter]

Hi Dan,

Is the report viewer placed in RadWindow? If this is the case this is logged in our bug system for investigation and in the meantime our suggestion is to avoid RadWindow.
We are sorry for the the inconvenience.

About the ContextSwitchDeadlock this is quite generic exception and we are unable to reproduce the exception on our end with the latest release of Telerik Reporting Q2 2011 Service pack 1. Thus, we would appreciate if you open a support thread and send us a runnable sample project that exhibits the problem. Once we review it, we would be able to provide you with more info.

All the best,
Peter
the Telerik team

[Michael]

Hi

"Is the report viewer placed in RadWindow? If this is the case this is logged in our bug system for investigation and in the meantime our suggestion is to avoid RadWindow.
We are sorry for the the inconvenience."
I've placed ReportViewer in WPF native Window object and I've got the same result; any sugestion?

Dan

[Michael]

Hi again

In addition to previous post, when I said same result I ment to the speed of renfdering exporting file not to menu...
Any sugestion/solution regarding the fact that it takes too much time to create export file?

Dan

[Michael]

ContextSwitchDeadlock appears before ReportViewer render export file when the process takes minutes; this is observed in Debug mode.
Dan

[Peter]

Hello Dan,

You can switch off the exception by unchecking
Debug->Exceptions->Managed Debugging Assistants->ContextSwitchDeadlock checkbox.

Generally you may find useful the following resources that elaborate on the exception:

• contextSwitchDeadlock MDA MSDN article;
• Why does the ContextSwitchDeadlock happens? MSDN forum thread;

About the performance we will need more information about your configuration and the report layout in order to reproduce and examine the reason for the slowdown. 

1. What is the report layout you are after? For table like layout we highly recommend Table item  that is optimized for such layout and performs better than table like layout with textboxes. 
2. Which report viewer do you use? 
3. Do you have horizontal paging? 
4. Do you use conditional formatting? 
5. The page count could also cause a delay if you are using the PageCount global object. 
6. Additionally we will appreciate if you elaborate on the server configuration OS, CPU, RAM and etc.

Be aware one has to keep in mind that handling reports (be it with large data or large number of report items) usually requires additional resources to handle all the operations. Those operations are complex and include data processing (aggregates, filtering, sorting, conditional formatting, expression evaluation, events) and rendering (fonts measurements, layout calculations, paging and etc.). However in our local tests the PDF rendering handles 1000 pages table report in 100 seconds. 

We highly recommend reviewing Performance Considerations KB that shares some general performance tips. Let us know how it goes and in order to investigate further we will appreciate if you open a support thread and send us the report definition and some dummy data to debug locally.

All the best,
Peter
the Telerik team

[Michael]

Hi Peter

Answers to your questions:
1. What is the report layout you are after?
R: I'm not using table, but reposrt as it is with groups (header & footer too) - at each group header level I have a chart with same DataSource as Report itself, details and so on. DataSource is List<MyBusinessObject>
2. Which report viewer do you use?
R: I'm using ReportViewer for WPF -Telerik.Reporting version: 5.1.11.713;
3. Do you have horizontal paging?
R: yes.
4. Do you use conditional formatting?
R: No.
5. The page count could also cause a delay if you are using the PageCount global object.
R: Yes, I'm using this.
6. OS: Windos 7 Enterprise 64 bit; CPU: Intel T9400 @ 2.53GHz; RAM: 4GB;

Important: even when Chart is disabled (data is not set for it and it's hidden) exporting time is greater than 10 minutes for 30 615 records; displaying reports takes 90 seconds.

I hope these helps.
Thanks
Dan

[Michael]

One more thing:
There is no way to anchor or dock ReportViewer to its container; is there any work around for this issue?
I have ReportViewer inside of a grid...

Thanks
Dan

[Steve]

Hi Dan,

We have several suggestions for improving the performance of the report:

• do not set the DataSource property of the chart in the groups directly. Since it uses the report data source, set a Binding for the Chart.DataSource property with =ReportItem.DataObject expression. For more information refer to this forum thread.
• Horizontal paging - occurs when the report does not fit on one page horizontally and has major impact on the performance. i.e. if you have 1000 pages high report, and horizontal paging appears, you will feel like paging not 1000 * 2, but ~ 1000 * 1000 pages. The bottom line is that in order to page long reports you should avoid horizontal paging at all costs.
• PageCount global object - this triggers an extra paging pass that depending on the report complexity may significantly increase the time for the rendering operation to complete.
• 10 000+ records: Improving the report's performance is a matter of finding the balance between complexity of the report and the amount of data. As far as the processing time (and consumed memory) is concerned, the complexity of the report layout, the number of report items, the number of pages and the complexity of the data calculations (aggregates, groupings and conditional formatting) are crucial. Our reporting engine provides unlimited flexibility in order to cover the scenarios of as many customers as possible. However when the aim is performance, one should strive for simplicity.

About your second inquiry, you can use the same approach to dock/anchor the report viewer as you would do with any other WPF control. For more information refer to Walkthrough: Arranging WPF Content on Windows Forms at Design Time.
Greetings,
Steve
the Telerik team