Canalblog
Editer l'article Suivre ce blog Administration + Créer mon blog
Publicité
share Thinking ...
share Thinking ...
  • I am an engineer in computer science. Software building is one of my first passions. I have a little more than 3 professional experience years....I won't let you discover all about me now, let's share here a while, maybe i will provide the help you need.
  • Accueil du blog
  • Créer un blog avec CanalBlog
Publicité
share Thinking ...
10 décembre 2008

Stack overflow of DataView object property rowfilter (.NEt framework)

I spent a lot of time to find out why the application pool crashs! I finally found out the reason: a stack overflow of DataView object property which is "Rowfilter" of .NET framework. At the begin, of course i did not know. Let's share the resolving way...

I worked on a web application! In its scope, there is a rights management applied to check any element access of the user (like document, product etc...). Then, on my debugging environment (visual studio 2005) i had no failure observed, as on UAT (pre-prod environment). But on the prod environment, when the user already logged tried to access to documents page, we got this error in the event viewer: ("A process serving application pool 'ASPNET2' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '4104'. The data field contains the error number.")
After five tentatives, the application pool stopped fully with this log in the event viewer: (Application pool 'ASPNET2' is being automatically disabled due to a series of failures in the process(es) serving that application pool.)
Obviously we lost the context and session! then the logout user was forced!

How to resolve it? i tried to find some resolutions ways on the web! But no way :-( ...I tried to reproduced the error on my debugging environment by using the prod database data! But i got no error! First step, i checked with the embedded web server of visual studio and in second step with the IIS server installed on the local machine with always using prod database data replication. But it ran with absolutely no failure.

Then my first deduction is that the problem was not due to the data type and volume of the prod environment. But my question stays available : Why this failure?  Debugging in prod environment requests some specific tools, and i don't have really access to it, almost i am not in charge to do it. But i found out other resolutions ways:

-It could be due to the account NT AUTHORITY / NETWORK which has no enought rights for keys registry access. Microsoft give details here. But it was not my case.

- I saw on the web, It could be due to the code depth. Then i optimized the application by using cache to reduce the database calls, and reduced at the maximum the potential code depthe by rewritting the main part of the page code. This does not resolve the problem.

- Then i have the last solution, by hidding step-by-step the code to find out the code part responsible of the failure! It's really heavy, and not easy as debugging method. But i  did not have any alternative! Then at each step, i deployed the code to dmz website to check the behavior!

I did it until to find out that the affecting rowfilter expression of one dataview with a new value allows to reproduce at any time the failure! I deduced that the rowfilter expression could be the main failure raison! But as i have no error in dev environment, i told to myself that the synthax is surely correct, otherwise i should have to get the failure on my local machine too. Then, by reproducing the scenario on my local machine, i watched this rowfilter expression and did the next remark:
rowfilter expression is too long with a lot of using keyword "OR"..It looks like (ID = 0 OR ID=2 OR ID=3......OR ID=n). Then replacing this expression by (ID IN (0,2,3....n)), i resolved the problem and since the time i get a better performance.

By limiting the n values to around 70 elements, i did no more have the failure. Then my advice is using "IN expression" rather than "OR expresion" in any similar case. You will avoid the stack overflow of dataview property rowfilter











Publicité
Publicité
Commentaires
Publicité