[midPoint] dirsync cookie size

Tue Sep 18 07:18:30 CEST 2018

Hello Andy,

I am glad it works. I've fixed the logging line (on master it was 
already OK).

As for the stack overflow exception, it does not happen often, but 
sometimes it does. It usually means that some tasks (in this case) are 
extraordinarily large. Could you export your tasks and check if this is 
the case?

The usual solution - or, more precisely said, workaround - is to 
increase JVM stack size.

Best regards,

Pavol Mederly
Software developer
evolveum.com

On 18.09.2018 6:47, Andrew Morgan wrote:
> Thanks Pavol and Davy for getting this fix in the support-3.8 branch too!
>
> I built support-3.8 today (pretty easy), and I installed it over my 
> existing 3.8 version in my DEV environment.  After making sure nothing 
> was obviously broken, I applied it in my PROD environment as well.  
> Our PROD environment has not rolled into full production yet.  We are 
> still operating in read-only mode.  LiveSync for AD is working!
>
> I found one annoyance.  There is some extra logging happening in my 
> midpoint.log, quite frequently:
>
> 2018-09-17 21:41:14,975 [] [midPointScheduler_Worker-5] INFO 
> (com.evolveum.midpoint.model.impl.lens.AssignmentEvaluator): 
> evalAssignment isVirtual false
>
> I tracked this down to a particular commit when I was at work earlier 
> today, but I don't have the commit handy here at home.  If you search 
> for "evalAssignment isVirtual", you'll find the code. I assume this 
> should be logging at DEBUG or TRACE instead of INFO.
>
> I also saw a StackOverflowError when I was doing something with 
> tasks.  I think I was resuming the tasks after the upgrade to 
> support-3.8.  It goes like this:
>
> 2018-09-17 15:09:21,404 [] [http-nio-127.0.0.1-8080-exec-2] ERROR 
> (org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/midpoint].[dispatcherServlet]): 
> Servlet.service() for servlet [dispatcherServlet] in context with path 
> [/midpoint] threw exception [Filter execution threw an exception] with 
> root cause
> java.lang.StackOverflowError: null
>         at 
> java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72)
>         at 
> sun.reflect.GeneratedSerializationConstructorAccessor562.newInstance(Unknown 
> Source)
>         at 
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>         at 
> java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:1091)
>         at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2052)
>         at 
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1572)
>         at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2286)
>         at 
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2210)
>
> and then the last 4 lines repeat many times.  The Apache logs show it 
> was these requests:
>
> 10.214.121.42 - - [17/Sep/2018:15:09:21 -0700] "GET 
> /midpoint/admin/tasks?7-1.IBehaviorListener.0-&_=1537222160890&windowName=ed330920-220c-4363-a008-56016f40a75e 
> HTTP/1.1" 500 72 
> "https://midpoint.iam.oregonstate.edu/midpoint/admin/tasks?7"
> 10.214.121.42 - - [17/Sep/2018:16:45:25 -0700] "GET 
> /midpoint/admin/tasks?8-1.IBehaviorListener.0-&_=1537227925115&windowName=23b7b8d1-0a9d-4e8e-a3c6-560db1fc3ed2 
> HTTP/1.1" 500 72 
> "https://midpoint.iam.oregonstate.edu/midpoint/admin/tasks?8"
>
> I hope this helps.  I can try to reproduce it again tomorrow at work.
>
> Thanks,
>
> Andy Morgan
> Systems Administrator, Identity & Access Management
> Information Services | Oregon State University
> 541-737-8877 | is.oregonstate.edu
>
> On Mon, 17 Sep 2018, Pavol Mederly wrote:
>
>> Hello,
>>
>> it's done. Please delete and re-import your live sync tasks after you 
>> apply the fixed midPoint version.
>>
>> In case of any problems, please let me know.
>>
>> Best regards,
>>
>> Pavol Mederly
>> Software developer
>> evolveum.com
>>
>>
>> On 17.09.2018 19:49, Davy Priem wrote:
>> Hi,
>>
>> Plz backport this to support branch. I can’t wait for 3.9 to be 
>> released.
>>
>> Best regards,
>> Davy
>>
>> Van: midPoint 
>> <midpoint-bounces at lists.evolveum.com><mailto:midpoint-bounces at lists.evolveum.com> 
>> Namens Pavol Mederly
>> Verzonden: Saturday, September 15, 2018 8:08 AM
>> Aan: midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>
>> Onderwerp: Re: [midPoint] dirsync cookie size
>>
>>
>> Hello Davy, Andrew,
>>
>> it is fixed in v3.9devel-810-g6ad3f2d. Took some time because there 
>> is really a lot of work these days.
>>
>> Davy, you say it blocks your deployment. Does this mean you need this 
>> patch to be backported to support-3.8 branch?
>>
>> Best regards,
>>
>> Pavol Mederly
>>
>> Software developer
>>
>> evolveum.com
>> On 07.09.2018 21:25, Davy Priem wrote:
>> Hi Andrew,
>>
>> I wanted to enable AD live sync on our production env and I got the 
>> same issue. I’ve created https://jira.evolveum.com/browse/MID-4878 
>> since this blocks our deployment.
>>
>> Davy Priem
>> IT technical management
>>
>> VIVES University of Applied Sciences | Dienst IT
>> Doorniksesteenweg 145 | 8500 Kortrijk
>>
>>
>>
>>
>> Op 4 sep. 2018, om 02:09 heeft Andrew Morgan 
>> <morgan at oregonstate.edu<mailto:morgan at oregonstate.edu>> het volgende 
>> geschreven:
>>
>> I want to use LiveSync against Active Directory.  I tested this 
>> against a DEV AD forest successfully.  However, our production AD 
>> forest sends back a dirsync cookie that is too large to store in the 
>> database.  Here is the error message:
>>
>> Caused by: java.sql.BatchUpdateException: (conn:2031) Data too long 
>> for column 'stringValue' at row 1
>> Query is: insert into m_object_ext_string (item_id, owner_oid, 
>> ownerType, stringValue) values (?, ?, ?, ?), parameters 
>> [3,'f82fdd36-4c48-4fb6-a63a-41b7a4c3d87c',0,'TVN
>> EUwMAAAAnXGd2x0LUAQAAAAAAAAAAYAEAAKtAqxsAAAAAAAAAAAAAAACrQKsbAAAAAHPlzWqF1FtDm1ZrUmr4u/MBAAAAAAAAAA4AAAAAAAAAhqWdCK+vK02geidsZEcwPLtShAEAAAAArof1HJPRtky2F91ymoTezNjxBg 
>>
>> AAAAAA46GJMRVAcU2tKRkmqVaV1J+dagAAAAAAcrUjMp5l50+jD8wFx6wJJjHD2xIAAAAAdpm4VNLlFka4g0XbrKotWMDcdgEAAAAAWKaYVZylhU6lcupRoF3dJ2Gu8xwAAAAAGuwbW5pZ9Uyj9C51G+Cn+XAreCwAAAAAc 
>>
>> +XNaoXUW0ObVmtSavi788RAqxsAAAAAFP87ecztkkC/rUXsZKbD3DJFlC8AAAAAQSkin09ZxEuR3AkpCse6hldb+AIAAAAAZTmHyMWZlEip9Ud4ctmZQcz3AAAAAAAApJnX7Zy8A0KPlWzyWh3+kBnSbAAAAAAAjuvm8MeE 
>>
>> 6UOQ5G8LLXFnsb/YBQAAAAAAoalZ8hHbSUiEDZ030itBSixrzQEAAAAA']
>>
>> stringValue is varchar(191), but the dirsync cooke is huge - 560 
>> characters long.
>>
>> Is this a known issue?
>>
>> Thanks,
>>
>> Andy Morgan
>> Systems Administrator, Identity & Access Management
>> Information Services | Oregon State University
>> 541-737-8877 | is.oregonstate.edu<http://is.oregonstate.edu>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> midPoint mailing list
>>
>> midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
>>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180918/39aec38a/attachment.htm>