John, can you enlighten me here?  Do you have a reproducible test case we could plug into one of our test orgs? 

Although the limits were removed in apex, there are far more problems with allowing people to loop over an essentially unlimited number of objects, creating who knows how many components on each iteration.  We simply didn't have the time we needed to test whether we had enough limits in place elsewhere to stop a runaway page from slowing everything down.  Usability wise, I would argue that it rarely makes sense to put more than 1000 of anything on your page, though with the right use cases we could reconsider.

For those who have posted in this thread, the addition of this limit was documented in the release notes on page 159.

This of course doesn't address whatever your current problem seems to be, which I'm not sure I understand.  You're saying that you have some sort of expression on your Visualforce page that is calling into a method in your controller, which is building up some type of collection, and that collection is never directly referenced by your page?  The limits should only be enforced when you're referencing the collection via one of our components that needs to iterate over it (repeat, pageBlockTable, etc.)  If you're seeing something different, I'd appreciate it if you could whip up a piece of code that demonstrates it for us.

The documentation you're asking for, John, doesn't exist per your explanation of the error, because I don't believe it should work that way (and see no evidence in our own implementation of it that it would, but I'm not saying there's not a bug here somewhere).

While in general I agree that you don't want to render more than 1000 items on a page, it seems arbitrary to make that a requirement for all pages. What is the actual resource that is being protected by this limit? Page size? There is still a heap size limit in Apex so the lists would not be unlimited. Much like what was done with removing the collection limit in Apex and relying on heap size instead, it may be better to have a limit on the resource being protected rather than an arbitrary limit.

In my specific case, I'm rendering a page as an excel spreadsheet. 1000 rows in a spreadsheet is too limiting IMHO. 

Hi Jill,

While I didn't start this thread I did end up with the exact same error the OP had.

When viewing a certain Visualforce page, one user was getting this error:

Collection size 1,911 exceeds maximum size of 1,000.

I asked the user to turn on debug logging, repeat the query, and & send me the result.

She did so, and I found exactly where the issue lies - in a loosely heuristic part of our code that tries to suggest Accounts for uncategorized email addresses.  This code tries to look at as much data as it can within query limits, but without the requirement that it sees all the relevant data.

The code chunk does 3 things:

a.  Figures out how many query rows it has left within its limits

b.  Uses a SOQL for-loop to query the relevant tables, bounded by (a)

c.  Adds the result to Map<string, Account> as long as the Map size is less than "SFDC.MAX_ARRAY", which is a constant defined in our code.

The debug trace dies right after the SOQL query, during step (c).  Our user had recently upgraded from a version where SFDC.MAX_ARRAY is defined as 1,000 to a version where SFDC.MAX_ARRAY was defined as 10,000.

I reverted the value of SFDC.MAX_ARRAY, she upgraded, and the error went away.

My read of the situation is that Maps are still limited at 1,000 elements when called in a Visualforce context, and Avrom's comments above seem to match that understanding.  Am I wrong about something?  Were Map sizes not uncapped in Spring '10 along with Array sizes?

Sorry, that wasn't what I had intended to imply. I'd just meant that a page couldn't render a list of >1000 components except in the SOSC case.

I'm not sure what you're reading into Avrom's comments but the limits should be exactly as they are stated in the documentation.  You can't bind pageBlockTable, dataTable, panelBar, repeat, or dataList to a collection larger than 1,000, full stop.  And as far as I know there should be no distinction between maps or lists.  In fact, our iterating components don't even work with maps (pretty sure there's an idea on IdeaExchange for that one already) so it wouldn't make sense for anything to die on this limit while filling up a map.

I just want to be clear that the limits have less to do with being called from a Visualforce context and more to do with the value bindings of our iterating components.  At least in theory.

John, a reproducible test case would do wonders for us in this situation.  Or you could go the support route and get us all the usual info/permissions we'd need to go about reproducing this.  Any other contributors to this thread are invited to do the same.

To James, I don't disagree with you at all.  As I said before it was more of a time thing.  We do have limits on the page size but we weren't sure that they were adequate enough to protect the system, and we chose to leave the limit in for the time being, as it's no more or less arbitrary than the previous 1,000 limit on collections in Apex.  I don't want to get into our own implementation details but I just wanted you to know that we did discuss exactly what you mentioned, we just chose to err on the side of caution.  Last thing we want is to remove the limit, find some nasty page that slows the system down, and then have to put the limit back in...

Avrom, thanks for the clarification.  It was this statement:

Collections referenced in other ways from VF pages have a maximum of 1000 rows.

That made me think you guys limited, say, Arrays in a Visualforce context.  The fact that it seemed to match what was happening to our user dovetailed with my read of the above.

I'll have to get back to you guys with a concise test case, then (if I can).  Our SFDC.MAX_ARRAY constant is used many places throughout our code, so it's possible that the bug did not happen during the Map<> building but later during a component binding attempt.  (in fact, I would assume that to be the case now).

Given that y'all are now saying that collection size limits are not enforced in Visualforce pages (only that component size limits are enforced when binding), I think it's safe to assume that the bug lies in my code (trying to bind a component) rather than in yours.