Grouper Users - Open Discussion List

[Jeffrey Crawford <>]

Actually looking at the log behaviour I'm wondering if I've somehow configured an infinate loop. The log is full of which just continues for what seems like forever:

Caused by: java.lang.StackOverflowError

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethResolutionContext.getResolvedDataConnectors(ShibbolethResolutionContext.java:84)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDataConnector(ShibbolethAttributeResolver.java:351)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDependencies(ShibbolethAttributeResolver.java:410)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:332)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDependencies(ShibbolethAttributeResolver.java:412)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:332)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDependencies(ShibbolethAttributeResolver.java:412)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:332)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDependencies(ShibbolethAttributeResolver.java:412)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:332)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDependencies(ShibbolethAttributeResolver.java:412)

        at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:332)

Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------

On Fri, Oct 28, 2016 at 2:09 PM, Jeffrey Crawford <> wrote:

Well I guess as long as it doesn't cause data problems, that may be fine. It just seems to make sense to only let one update the data so they don't fight each other. If that's already a use case then perhaps I don't need to worry about it.

Not too worried about load at the moment, Would it cause double audit entries?

Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------

On Fri, Oct 28, 2016 at 12:46 PM, Bee-Lindgren, Bert <> wrote:

I don't know yet if it is necessary to separate the psp instances, but... What is the downside to  letting the second one process loader jobs? (My Guess: Increased load on the source systems)

Just curious,

  Bert

---

From: <> on behalf of Jeffrey Crawford <>
Sent: Friday, October 28, 2016 3:34 PM
To: Gouper Users List
Subject: [grouper-users] Re: Stack overflow when provisioning one stem to multiple targets

 

And if I do need to separate them, how do I prevent the other one from processing the loader jobs?

Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------

On Fri, Oct 28, 2016 at 12:04 PM, Jeffrey Crawford <> wrote:

Good Morning,

I hesitate to bring this up since it's on the old psp version but when I try to provision parts of one stem to multiple psp targets. I'm getting a stack error:

What I'm doing as an example is consider the following stem

ucsc:org:its:win

I provision ucsc:org:its to an ldap server and ucsc:org:its:win to an AD. It stop right at the point the AD provisioner tries to run with the following error.

Any ideas, or do I need to run a daemon for each target?

Problem calling method fullSync on edu.internet2.middleware.psp.grouper.PspChangeLogConsumer

        at edu.internet2.middleware.grouper.util.GrouperUtil.invokeMethod(GrouperUtil.java:4126)

        at edu.internet2.middleware.grouper.util.GrouperUtil.callMethod(GrouperUtil.java:4063)

        at edu.internet2.middleware.grouper.util.GrouperUtil.callMethod(GrouperUtil.java:4247)

        at edu.internet2.middleware.grouper.app.loader.GrouperLoaderType$10.runJob(GrouperLoaderType.java:1176)

        at edu.internet2.middleware.grouper.app.loader.GrouperLoaderJob.runJob(GrouperLoaderJob.java:416)

        at edu.internet2.middleware.grouper.app.loader.GrouperLoaderJob.execute(GrouperLoaderJob.java:318)

        at org.quartz.core.JobRunShell.run(JobRunShell.java:202)

        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)

Caused by: java.lang.reflect.InvocationTargetException

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:498)

        at edu.internet2.middleware.grouper.util.GrouperUtil.invokeMethod(GrouperUtil.java:4112)

        ... 7 more

Caused by: java.lang.StackOverflowError

Jeffrey E. Crawford
Enterprise Service Team

Both pilots and IT professionals require training and currency before charging into clouds!

---------------------------------------