ASP.NET Report Viewer & multiple IIS Worker Processes

[AndySWS24]

Hi, we've just updated to runtime version 13_0_37 and Crystal decisions 13.0.4000.0   (64 bit)

Our application is configured to use 5 IIS Worker Processes, but since the upgrade we have a problem with the report viewer "losing" its parameter. We believe this is when the client connection is processed by another Worker Process after the report is loaded. So you run a report, it prompts for the parameter and it shows correctly, however then when attempting to change the View %, it intermittently re-prompts for the parameter. Or when exporting, intermittently nothing happens after you click export.

We have ReuseParameterValuesOnRefresh="true" on the viewer - it was working ok before we upgraded the Crystal version used. Session is shared using StateServer service.

Setting maximum worker processes to 1 works around the issue but I'd like to be able to have multiple worker processes.

Is this a known issue or anything I can try? There are no errors reported in the browser dev tools. I read somewhere that Crystal expects its memory in a contiguous block, I guess this is the issue with different processes serving the requests, but not sure why its only become an issue in this version. Maybe because its 64 bit?

[AndySWS24]

Just to add/clarify... a report with no parameters exports every time without issue.

[DonWilliams]

Hi Andy,

The problem you are having is because you need to use Sessions, the Report request is not going to the original Object but starting a new instance

See this KBA on how to:

https://userapps.support.sap.com/sap/support/knowledge/en/1985571

Don

[AndySWS24]

Hi Don, that suggestion doesn't help. The ReportDocument that is saved to Session is before the client prompts the user for parameter value - I've just tried it with a single worker process and it prompts for the parameter again every time you do anything. It is working fine without session other than the client end prompted parameters... are the client/user entered parameter not stored in ViewState or a form field, they can't be part of the ReportDocument because the value is not known when it is loaded. thanks

[DonWilliams]

Are sticky sessions enabled in IIS? That's a must do, consult MS doc's on how to enable. Sessions is a must though, so the request doesn't get sent to a different Web Server when the Report is open in this one... Must also be using PostBack also so it again goes back to the same session... KBA shows you how to.

[AndySWS24]

Hi Don, Sticky sessions are not applicable, there is no load balancer involved, just a single server where the IIS AppPool has multiple worker processes

[DonWilliams]

Ah yes, right, only required when a LB is used. Likely cause then is threading issue, you need to keep track of which thread/IIS Instance the report is using and make sure any requests go back to that IIS Process.

[AndySWS24]

Hi Don, are we able to ask the developers about this behaviour because I can't see how you can control postbacks to be within one Thread/memory/process. thanks

[DonWilliams]

With a threaded App you wouldn't need to use PostBack, you create a thread for each Report object and use the thread to maintain focus... I'll ping them and see what they say...

[DonWilliams]

R&D is wondering what SP you upgraded from? They say nothing has changed in this area...

[AndySWS24]

Hi, it was 13_0_24 but I was running 32 bit, the App Pool had "Enable 32 bit" set to True, but when I installed 13_0_37 I couldn't get 32 bit to work (despite having the runtime installed) so I changed the project & App pool to 64 bit - therefore I'm not sure if it's the change in version as such or the change in bitness. It would be great if they could give an indication into what can be checked/tested. I still think the Client prompted parameter must/should be within the viewstate/postback? I have a machine key within the web.config file (I believe it's used with multiple worker processes) but maybe that's not being picked up correctly for some reason. Any help greatly appreciated! Thanks

[DonWilliams]

That's odd that 32 bit wouldn't work, I assume you installed the 32 bit runtime when prompted at the end of the EXE install and not just run the MSI package? That may be the difference, we'll see what R&D has to say with this new info

[AndySWS24]

Yes, on my Dev PC everything seemed ok but on runtime server, I ran the two separate installs for 32 bit and 64 bit but 32 bit gave a Class error (dont have the specific error now but could probably reproduce it if helpful) I tried lots of things but in the end decided to move to 64 bit

[DonWilliams]

It could be missing dependencies maybe... I sent you a direct message with info on how to possibly fix your issue that was due to a security update in SP 27

[AndySWS24]

Thanks Don, I will try the suggestion. For some reasons, it will be 10-14 days before I am able to report back. Many thanks