Grouper Users - Open Discussion List

[Tom Zeller <>]

The stack trace below is attempting to retrieve attributes from a JNDI
subject in order to calculate provisioning, so this is during a
synchronization iteration.

In the logs, you should see something like

 INFO  edu.internet2.middleware.ldappc.spml.PSPCLI.run(105) -  -
Starting ldappc-ng
 ...
 INFO  edu.internet2.middleware.ldappc.spml.PSPCLI.run(141) -  - End
of ldappc-ng execution : 145 ms

indicating synchronization cycles.

So, Scott needs to wait until he sees the cycle end in the log and
then run jstack ?

TomZ

On Mon, Oct 11, 2010 at 10:41 AM, Chris Hyzer 
<>
 wrote:
> The stack says that this is the thread doing the work (below):
>
> To confirm this, you can do:
>
> top -Hp 12345    (where 12345 is the process id)
> Then you see the threads, and the one with 70-100% cpu, see the ID, and you 
> should see that in jstack in HEX.  So if the thread ID is 24247, then HEX 
> it is 0x5eb7, you see that as the "nid" in the jstack.  Anyways, if that is 
> the thread doing the work (which if it isn't, then based on your jstack, 
> then it is a JVM problem... no other threads are doing much), then maybe 
> TomZ could respond as to why it is doing so much work...
>
> Thanks,
> Chris
>
>
>
>
> "Timer-2" prio=10 tid=0x00000000435bf800 nid=0x5eb7 waiting for monitor 
> entry [0x00007fe877bf3000]
>   java.lang.Thread.State: BLOCKED (on object monitor)
>        at com.sun.jndi.ldap.Connection.unpauseReader(Connection.java:741)
>        - locked <0x00007fe89864c320> (a java.lang.Object)
>        at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:387)
>        at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:370)
>        at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:528)
>        at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
>        at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
>        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
>        at 
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
>        at 
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
>        at 
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
>        at 
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
>        at 
> edu.internet2.middleware.subject.provider.JNDISourceAdapter.getLdapResults(JNDISourceAdapter.java:410)
>        at 
> edu.internet2.middleware.subject.provider.JNDISourceAdapter.getLdapUnique(JNDISourceAdapter.java:441)
>        at 
> edu.internet2.middleware.subject.provider.JNDISourceAdapter.getSubject(JNDISourceAdapter.java:130)
>        at 
> edu.internet2.middleware.grouper.subj.SourcesXmlResolver.find(SourcesXmlResolver.java:122)
>        at 
> edu.internet2.middleware.grouper.subj.CachingResolver.find(CachingResolver.java:111)
>        at 
> edu.internet2.middleware.grouper.subj.ValidatingResolver.find(ValidatingResolver.java:94)
>        at 
> edu.internet2.middleware.grouper.SubjectFinder.findById(SubjectFinder.java:635)
>        at 
> edu.internet2.middleware.grouper.subj.LazySubject.getSubject(LazySubject.java:200)
>        at 
> edu.internet2.middleware.grouper.subj.LazySubject.getAttributeValues(LazySubject.java:131)
>        at 
> edu.internet2.middleware.grouper.shibboleth.attributeDefinition.MemberAttributeDefinition.doResolve(MemberAttributeDefinition.java:98)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.BaseAttributeDefinition.resolve(BaseAttributeDefinition.java:107)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.BaseAttributeDefinition.resolve(BaseAttributeDefinition.java:38)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ContextualAttributeDefinition.resolve(ContextualAttributeDefinition.java:92)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ContextualAttributeDefinition.resolve(ContextualAttributeDefinition.java:32)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:306)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttributes(ShibbolethAttributeResolver.java:257)
>        at 
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttributes(ShibbolethAttributeResolver.java:130)
>        at 
> edu.internet2.middleware.grouper.shibboleth.attribute.SimpleAttributeAuthority.getAttributes(SimpleAttributeAuthority.java:93)
>        at 
> edu.internet2.middleware.grouper.shibboleth.attribute.SimpleAttributeAuthority.getAttributes(SimpleAttributeAuthority.java:36)
>        at 
> edu.internet2.middleware.ldappc.spml.PSP.getProvisioningContext(PSP.java:774)
>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:174)
>        at 
> edu.internet2.middleware.ldappc.spml.PSPDiffer.diff(PSPDiffer.java:112)
>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:221)
>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:581)
>        at edu.internet2.middleware.ldappc.spml.PSP.execute(PSP.java:657)
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Scott Koranda
> Sent: Tuesday, October 05, 2010 2:49 PM
> To: Chris Hyzer
> Cc: Tom Zeller; 
> 
> Subject: Re: [grouper-users] ldappcng performance questions
>
>> Run jstack (packaged with sun java6) and the pid, a few times, and send it 
>> along, and we can see what it is doing...
>
> Hi,
>
> I started ldappcng like this:
>
> sudo -u tomcat6 ./bin/gsh.sh -ldappcng -bulkSync interval 60
>
> I then waited until I saw the XML output indicating (I think)
> a complete synchronization cycle. At that point I then ran
>
> sudo jstack 24145
>
> I didn't get any output from that command in the terminal in
> which I ran it, but I did see stack traces printed to the
> terminal in which gsh.sh was running.
>
> After that I sent gsh.sh a SIGTERM.
>
> I have put the entire session output from gsh.sh as a gzipped
> file at
>
> http://www.lsc-group.phys.uwm.edu/~skoranda/gsh.out.05Oct2010.gz
>
> Please let me know if there is any more information I can
> provide or if I should do something differently.
>
> Thanks,
>
> Scott
>