directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kiran Ayyagari (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRAPI-13) Recursively drilling into the directory structure causes java.lang.OutOfMemoryError
Date Tue, 27 Apr 2010 06:59:33 GMT

    [ https://issues.apache.org/jira/browse/DIRAPI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861264#action_12861264
] 

Kiran Ayyagari commented on DIRAPI-13:
--------------------------------------


Note that you need to close the cursors otherwise they still keep receiving the entries from
the server and stored in memory. Though you think the program
failed just after processing 52 entries, behind the scenes the earlier opened cursors are
still receiving entries, note that your program has opened 52 
cursors and all are left open!.
 
It would be good to know how you are performing the same task with other APIs, do you mind
attaching the code as a test case?

> Recursively drilling into the directory structure causes java.lang.OutOfMemoryError
> -----------------------------------------------------------------------------------
>
>                 Key: DIRAPI-13
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-13
>             Project: Directory client API
>          Issue Type: Bug
>    Affects Versions: 0.2.0
>         Environment: Windows XP SP3
>            Reporter: Sebu Koleth
>
>         private static void recursivelyDescend(LdapConnection connection, String dn)
{
> 		System.out.println("Searching for children of dn : " + dn);
> 		try 
> 		{
> 			Cursor<SearchResponse> cursor = connection.search(dn, "(objectclass=*)", SearchScope.ONELEVEL,
"*");
> 			while (cursor.next())
> 			{
> 				SearchResponse response = cursor.get();
> 				if(response instanceof SearchResultEntry) {
> 					recursivelyDescend(connection, ((SearchResultEntry)response).getObjectName().getName());
> 				} else {
> 					System.out.println("Unusable response type " + response);
> 				}
> 			}
> 		} catch (LdapException le) {
> 			le.printStackTrace();
> 		} catch (Exception e) {
> 			e.printStackTrace();
> 		}
> 	}
> The above piece of code is exercised after obtaining an SSL-based LDAP connection. The
target server has hundreds of thousands of records at different levels. Logging at WARN level
shows a *lot* of messages :
> WARN NioProcessor-1 org.apache.directory.shared.asn1.ber.Asn1Decoder - The PDU has been
fully decoded but there are still bytes in the buffer.
> The code chokes at processing the 52nd entry that is two levels deep from the base DN.
At this level there are around 1000 sub-levels.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message