It should *not* be the case that requesting
/system/userManager/user/<userid>.json causes listChildren() to be
called. If it does, that's a bug (but eyeballing the code, this doesn't
seem possible). Requesting /system/userManager/user.2.json will cause
listChildren() to be called.

In terms of your larger point, ResourceProvider.listChildren() returns
an Iterator and AuthorizableResourceProvider.listChildren() return value
simply wraps the result of getPrincipals(), so in and of itself, this
shouldn't exhaust memory.

What is probably necessary is to put some guard in place so that only X
number of items are returned and if more than X results are available,
support some kind of paging (I don't know what X should be). This would
be similar to SLING-1308. Actually, why isn't the code from SLING-1308
being invoked in your case? That seems very suspicious.

Sorry to hear about your bad release.

Justin


On 11/21/10 4:05 PM, Ian Boston wrote:
> Hi,
> In AuthorizableResourceProvider there is a call to 
> principalManager.getPrincipals(searchType);
> 
> IIUC that lists all authorizables that match the search type. Eg, all users 
> or all groups or all authorizables.
> 
> This is probably Ok with 100 users, but not so ok with 25K users and 40K 
> groups, as its called every time to do a call to 
> http://localhost:8080/system/userManager/user/<userid>.json
> 
> Did I understand correctly or am I reading the code incorrectly ?
> 
> I think the stack trace is something like
> AuthorizableResourceProvider.listChildren
> PrincipalManagerImpl.getPrincipals
> DefaultPrincipalProvider.getPrincipals
> DefaultPrincipalProvider.findPrincipals with a null search filter (ie all the 
> known Principals matching that type)
> 
> Obviously AuthorizableResourceProvider.listChildren *should* list all 
> Authorizables, but since in  most systems that identify the users, there 
> could be millions, this is probably not a good idea.
> 
> AuthorizableResourceProvider should probably not list children as doing so 
> will almost certainly crash the server for anything other than a trivial case.
> 
> WDYT?
> Ian
> 
> 
> BTW, I must apologise for not doing much work on Sling in the last month, our 
> release did not go smoothy and I have been firefighting. (fire still 
> smouldering)
> 

Reply via email to