I have a page where I am pulling a dataset from the database, a few thousand records. I get it when the page is loaded and store it in the cache. Each time an operation is performed on the page, I check the cache to see if its still there, and if not, go get it again (20 minute expiration); fairly typical setup.
When I run the page, the initial data loads fine, and a default RowFilter is applied to the data. When I change the value of a dropdown (which changes the RowFilter), the page hangs for a moment, then returns a javascript error:
Line: 80772370 (yes, thats line 80 million...)
Char: 17
Error: Syntax error
Code: 0
URL: -the url of the page I'm on-
This error is repeated EXACTLY 20 times.
When I re-run the page and the operation that renders that error, I get a different line number (for example, the next time I ran it after I posted the above message, the line is at 80718666), exactly 20 times again.
Now a few curveballs:
I was having the exact same issues when I was using the Session to store the data rather than the cache.
I do not have this problem in the development environment (this is happening in QA). The web.config for each environment are nearly identical, but the primary difference between them is that QA uses a sessionState server that is separate from itself. This is why I moved from Session variables to the cache in the first place.
When the search criteria is intended to return no results at all, it performs as it should (shows no results).
Now this hasn't exactly been my best week, so maybe I'm missing something big, but I could use some guidance.
Thanks SO community.
if you use UpdatePanel, remove it to see what's the real error is because now the error is hidden on a javascript return string, in the position you mention.
After you find your error, bring up again the UpdatePanel.
I can assume that the error is a null object/control that have been cached, and you forget to check if it not null.
When you cache parts on your page, and controls, then you need to check them on your back code, if they are null before use them.
Related
I'm using VS2010 and the built-in visual Report Designer to create RDLC templates for rendering reports with sub-reports as PDF files in an ASP.NET application using a ReportViewer control and the .LocalReport member. The code iterates over a set of records, producing one report (with its sub-reports) for each record.
I noticed recently that for a small number of the reports, one of the sub-reports was failing and giving the "Error: Subreport could not be shown" message. What's puzzling me about this case, in contrast to the many posts about this error that I've read (and previous times I've wrestled with it myself), is that it is only occurring for a subset of cases; from what I've seen elsewhere, the problem is usually all-or-nothing -- this error always appears until a solution is found, then this error never appears.
So... what could cause this error for only a subset of records? I can run the offending sub-report directly without errors; I can open the .xsd file and preview the DataSet for the offending records without errors; I can run the query behind the DataSet in SQL Server Mgt Studio without errors... I'm not sure where else to look for the cause(s) of this problem which only appears when I run the report-with-subreports?
I tracked this down to an out-of-date .xsd file (DataSet) -- somewhere along the way a table column string width was increased, but the DataSet was not updated or regenerated, so it still had the old width limit on that element, e.g., <xs:maxLength value="50" /> in the .xsd XML instead of the new width of 125 characters. The error was being thrown for those cases where at least one record in the subreport had a data value (string) in that column that exceeded the old width of 50.
An important clue came from adding a handler for the DataSet's .Selected event; I was already using the .Selecting event to set the sub-report's parameter (to tie it to the parent record), but I couldn't see anything useful when breaking in that event. However, examining the event args variable in the .Selected event, after the selection should have occurred, I found an Exception ("Exception has been thrown by the target of an invocation") with an InnerException ("Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints"). There was also a stack trace which indicated the point of failure was executing Adapter.Fill(dataTable).
While this turned out to be pretty misleading -- I had no such constraints in place on the tables involved in the query behind the DataSet -- it at least got me focusing on the specific records in the subreports. After much fruitless searching for anomalies in the subreport record data SQL Server Mgt Studio, I eventually started removing the records one-by-one from one of the offending subreport cases, re-running the report each time to see if I had fixed the error. Eventually I removed a subreport record and the report worked -- the remaining subreport records appeared!
Now I had a specific sub-report record to examine more closely. By chance (wish I could call it inspired intuition...), I decided to edit that record in the web app instead of looking at it as I had been in SQL Server. One of the fields was flagged with an alert saying the string value was too long! That was a mystery to me for a moment: if the string value was too long, how could it already be saved in the database?! I double-checked the column definition in the table, and found it was longer than what the web-app front-end was trying to enforce. I then realized that the column had been expanded without updating the app UI, and I suspected immediately that the .xsd file also had not been updated... Bingo!
There are probably a number of morals to this story, and it leaves me with a familiar and unwelcome feeling that I'm not doing some things as intelligently as I ought. One moral: always update (or better and usually simpler, just re-build) your .xsd DataSet files whenever you change a query or table that its based on... easier said than remembered, however. The queasy feeling I have is that there must be some way that I haven't figured out to avoid building brittle apps where a column width that's defined in the database is also separately coded into the UI and/or code-behind to provide user feedback and/or do data validation... suggestions on how to manage that more robustly are welcome!
On a new website, I've an huge formular(meaning really big, needs at least 15-20min to finish it), that configure the whole website for one client for the next year.
It's distributed between several tabs(it's a wizard). Every time we go to the next tab, it makes a regular(non ajax) call to the server that generate the next "page". The previous informations are stored in the session(an object with a custom binder).
Everything was working fine until we test it today with all real data. Real data needs reflexion, work to find correct elements, ... And it takes times.
The problem we got is that the View receive a Model partialy empty. The session duration is set to 1440 minutes(and in IIS too). For now what I know is that I get a NullException the first time I try to access the Model into my view.
I'm checking the controller since something like 1 hour, but it's just impossible it gives a null model. If I put all those data very fast, I don't have any problem(but it's random data).
For now I did only manage to reproduce this problem on the IIS server, and I'm checking elmah logs to debug it, so it's not so easy to reproduce it.
Have you just any idea about how should I debug this? I'm a little lost here
I think you should assume session does not offer reliable persistence. I am not sure about details but I guess it will start freeing some elements when it exceeds its memory limit.
You will be safer if you use database to store that information or you could introduce your own implementation for persisting state.
in addition to ans provided by #Ufuk
you can easily send an ajax request every 1 minute which would actually do nothing but by doing this the session wont get expired and site will continue to run in extended periods
The problem was that the sessions wasn't having enough space I think. I resolved temporary my problem by restarting the application pool. Still searching a solution that will not implies to changes all this code. Maybe with other mode of session states, but I need to make my models serializable.
I have a very strange problem with a website where several objects are cached.
We have a lot of DataTables, strings, booleans and other stuff that are cached for quick fetching in later requests.
Sometimes we get a periodic error where it looks like some of the cache items have been mixed up.
An example of how this shows itself is when a piece of code fetches a DataTable from the cache and then tries to access a certain column of that DataTable.
We then see a yellow screen of death with the exception "Cannot find column [ColumnName]", where "ColumnName" of course is some column name that was supposed to be in the DataTable.
When I inspect the cache item with a little home made tool, I see that a completely different DataTable is in the cache item. It is almost like some of the cache items have been mixed up.
Does anybody have an idea how this happens?
We are not able to reproduce the error. It occurs at apparently random intervals.
Whats the issue
When you add items to the cache, you need to lock the process that you create them and added to the cache.
First lets clarify that the cache is keep a reference to your data, is not clone them, nether knows whats is not that data ! reference: http://msdn.microsoft.com/en-us/library/6hbbsfk6(VS.71).aspx
Second clarify that the default session of a page is lock the pages and is by make most of the request safe because all users lock until a page fully load and send.
When its appear
So the lock issue may appear when you try to make cache by a thread, or by a handler, or by a page that have session off.
How to lock
If you use only one pool, then the simple lock(object){} can work, if you use many pools then you need to use mutex() for lock
You need to lock the full process of making your data if you change them later and still existing on cache, or only the cache reference if you make clone of them.
For example, if you read some data that you have get from the cache, then the time you edit them, if some other read the same cache it will get corrupted data, because the cache is give you a reference to them.
Hope that all this helps.
I've got a site that uses an order entry form and sends a rather decently sized POST request when the form is submitted.
However, when a particular value is passed in one of our form variables (OrderDetail), every time without fail, it gets an error page in the browser and a 504 error via Fiddler.
Here are a couple examples of tests I ran last night sending POST requests through Fiddler. When the "OrderDetail=" value is changed to the below it will either submit successfully or return a 504 error after a few seconds:
These ones FAIL:
&OrderDetail=Deliver+Writ+of+Execution%3B+and+Application+for+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff+DASH+Court+Services+Division+per+instructions
&OrderDetail=Deliver+Execution+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff+DASH+Court+Services+Division+per+instructions
&OrderDetail=Deliver+Writ+of+Execution%3B+and+Application+for+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff
&OrderDetail=Deliver+Writ+of+Execution%3B+Application+for+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff
&OrderDetail=Writ+of+Withholding+Execution+Order+Los+Angeles+County+Sheriff
&OrderDetail=writ+Execution+adsfsdfsdfsd+Order+County
&OrderDetail=wd+Execution+adsfsdfsdfsd+Order+Count
This got me thinking that perhaps it has to do with the words "Exec" ('Exec' and 'Execution' throw errors, 'Exe' does not) and "Count" ('County' and 'Count' throw errors, 'Cont' does not)
However, I haven't seen anything this specific mentioned in google searches regarding the 504 error.
Regarding the Coldfusion code around this, there is nothing fancy for this page. Just a standard form post. I added a cfmail test in the Application file and on these failures it is never ran, so this seems to be between the browser and IIS. We're on a shared server, so I can't see too much there, though.
Oddly enough, when the &OrderDetail= param is changed to one of these values (very similar to the above), the result is success:
&OrderDetail=wd+Execution+adsfsdfsdfsd+Order+Coun
&OrderDetail=wd+Execution+adsfsdfsdfsd+Order+Conty
&OrderDetail=Writ+of+Withholding+Order+Execution+Los+Angeles+County+Sheriff
&OrderDetail=Writ+of+Withholding+ExecutionOrder+Los+Angeles+County+Sheriff
In the 3rd one, I put 'Order' BEFORE 'Execution' and it works..
The total length of this POST request is about 4720 characters. I've increased the length of this one field to 5-6 times its length and they passed, so it almost seems tied to the value of the "&OrderDetail" param in the POST.
Any ideas on why this specific data could be an issue for a web server? I've never seen this before and it doesn't continue to be a problem for nearly any other request going through.
One interesting note as well: In the POST request, this variable is pretty close to the start of the param list. If I delete everything after it, it goes with no problem. Although I haven't been able to nail down what in the subsequent lines could be causing it. I can post the entire request if it will help.
More importantly though, I just want to know what could qualify as "reserved" or "illegal" for FORM data. Everything appears to be escaped properly so I'm not sure what else can be done here except for some pre-processing javascript to further escape any such words.
Thanks!
Given that EXEC and COUNT are causing the error, whilst putting ORDER before EXEC is preventing the error, this sounds like something is making a flawed attempt at protecting from SQL injection attacks.
If you have any software in place that claims to do that, I would see if (temporarily) disabling it stops the problem from occurring.
(This software might be at the firewall level, so you may need to talk to your sys admins.)
Importantly, I would also check your codebase for where OrderDetail is used, and make sure that it is using cfqueryparam whenever it is used inside a query - and the same goes for all other user-supplied data.
In a recent project we are currently getting 12031 errors. here is the complete error:
Sys.WebForms.PageRequestManagerServerErrorException 12031
the status code returned from the
server was 12031
The problem is, this doesn't happen all the time and we are unable to reproduce the error on development environment.
We use AJAX in our application and this exception happens on every page once in a while.
I've found a post on SO with the same problem and tried changing maxRequestLength to "1" to see if I constantly get the same error but I don't. Instead, I'm getting
Maximum request length exceeded.
So I'm starting to think that it is not related to maxRequestLength. I'm actually out of ideas. I have a ScriptManager in my MasterPage and its AsyncPostBackTimeout="240". That is the same amount of time (give or take). I get the 12031 error after 3,5 minutes of "nothing". I'm logging one of the pages and by logging, I mean logging every section of the page like "Page_Load is called" "xyz is called" etc and I have like 15 spots on the page for this. After user clicks a button and ScriptManager tries to do its job, no postback occurs, no logging happens. It is like the page wants to do a postback but too old to do it. Tries this for around 3,5 minutes and fails with the given error.
Please, if you have any ideas, HELP ME OUT .
Thank you
That error almost certainly has nothing to do with the size of the response, AsyncPostBackTimeout, or maxRequestLength.
Connection resets are usually indicative of poor network connectivity or a server loaded down to its capacity limits. A few things you could try:
Inspect the Windows Event Log during the time(s) that the kiosks were known to have received the error. Look for any relevant errors or warnings.
If feasible, ask the kiosk staff to use something like Pingtest to test the quality of their local network connection at the time that they receive the error in your app.
Use a service like Pingdom to ensure that the server itself isn't intermittently losing connectivity.
This error may be due to the HTTP Runtime limitation of the maxRequestLength. The default value is 4096.
Try adding (or editing) the following entry in your Web.Config:
"<httpRuntime maxRequestLength="8192" />" (effectively allowing 8mb of data transmission, instead of the default 4mb).
Please not....You can set data as per you max request. 8192 is not the limit. Also you need to add Page.Form.Attributes.Add("enctype", "multipart/form-data"); in Page_Load event of the page.
You'll want to enter this in the System.Web configuration section.
How do I avoid getting a PageRequestManagerParserErrorException?
To start with, don't do anything from the preceding list! Here's a matching list of how to avoid a given error (when possible):
Calls to Response.Write():
Place an or similar control on your page and set its Text property. The added benefit is that your pages will be valid HTML. When using Response.Write() you typically end up with pages that contain invalid markup.
Response filters:
The fix might just be to not use the filter. They're not used very often anyway. If possible, filter things at the control level and not at the response level.
HttpModules:Same as response filters.
Server trace is enabled:
Use some other form of tracing, such as writing to a log file, the Windows event log, or a custom mechanism.
Calls to Server.Transfer():
I'm not really sure why people use Server.Transfer() at all. Perhaps it's a legacy thing from Classic ASP. I'd suggest using Response.Redirect() with query string parameters or cross-page posting.
Another way to avoid the parse error is to do a regular postback instead of an asynchronous postback. For example, if you have a button that absolutely must do a Server.Transfer(), make it do regular postbacks. There are a number of ways of doing this:
The easiest is to simply place the button outside of any UpdatePanels. Unfortunately the layout of your page might not allow for this.
Add a PostBackTrigger to your UpdatePanel that points at the button. This works great if the button is declared statically through markup on the page.
Call ScriptManager.RegisterPostBackControl() and pass in the button in question. This is the best solution for controls that are added dynamically, such as those inside a repeating template.
Good luck!
I have received this error before when we had a Barracuda Device sitting in front of our website. It was a maximum request length issue because Barracuda protects against overloading the request size. We removed the device temporarily and it solved the problem. Not sure if this is your problem.