Hi, > > Currently I see only one reliable way to avoid it: use TABLE based ID > strategy for all objects. > > WDYT? > > A little overhead during the development phase but stronger in fact. > I can agree.
I would like to know other's opinions as well before create a Jira. Has anybody better solution? Do we need some more experiments? Cheers, Andrei. > -----Original Message----- > From: Fabio Martelli [mailto:fabio.marte...@gmail.com] > Sent: Dienstag, 29. Januar 2013 10:16 > To: dev@syncope.apache.org > Subject: Re: [Question] Problem with test UsertTestITCase.issueSYNCOPE279 > > > Il giorno 29/gen/2013, alle ore 10.10, Andrei Shakirin ha scritto: > > > Hi Fabio, > > > >> Hi Andrei, I found the problem: into the > >> AbstractPropagationTaskExecutor, line 334, the call to > >> getRemoteObject have to be encapsulated into a try- catch body. > >> As you can see, this is not an issue related to the TimeoutException > >> only but it is an issue of the whole propagation process. > > > > OK, sounds reasonable. Propagation exceptions should be wrapped on > high level exception like SCCEE. > > Just curious how this test runs by you before? Is there the same reason as > in my topic (2)? > > Really I don't know. Probably (2) is the main reason. > > > > >> This is terrible: why the creation of a new virtual attribute should fail? > >> Doesn't UVirAttr id auto generation work fine anymore? > >> Can you investigate more? > > > > I already have seen the same effect with Notification DAO object: > discussion http://mail-archives.apache.org/mod_mbox/syncope- > dev/201301.mbox/%3c50f3c43f.1000...@apache.org%3E . > > It seems that AUTO generation strategy doesn't work properly under high > volume/ high concurrency at least for H2 DB. > > > > Currently I see only one reliable way to avoid it: use TABLE based ID > strategy for all objects. > > WDYT? > > A little overhead during the development phase but stronger in fact. > I can agree. > > Regards, > F. > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Fabio Martelli [mailto:fabio.marte...@gmail.com] > >> Sent: Dienstag, 29. Januar 2013 09:40 > >> To: Andrei Shakirin > >> Cc: dev@syncope.apache.org > >> Subject: Re: [Question] Problem with test > >> UsertTestITCase.issueSYNCOPE279 > >> > >> > >> Il giorno 28/gen/2013, alle ore 18.54, Andrei Shakirin ha scritto: > >> > >>> Hi Fabio, > >>> > >>> Investigated a little bit more and found the following: > >>> > >>> 1. TimeoutException > >>>> This is the expected exception: it should be handled and returned > >>>> as a SyncopeClientErrorException. > >>> > >>> Not really. As far as I can see TimeoutException thrown by > >> ConnectorFacadeProxy.getObject() is never wrapped to > >> SyncopeClientErrorException. > >>> Check the whole chain: UserController.create() -> > >>> UserController.createInternal() -> taskExecutor.execute() -> > >>> PriorityPropagationTaskExecutor.execute() -> > >>> AbstractPropagationTaskExecutor.getRemoteObject() -> > >>> ConnectorFacadeProxy.getObject(); > >>> > >>> AbstractPropagationTaskExecutor.getRemoteObject() just re-throws > the > >> Timeout exception. > >>> syncopeClientError.jsp doesn't handle the TimeoutException and > >>> returns > >> InternalServerError that I get from my test. > >> > >> Hi Andrei, I found the problem: into the > >> AbstractPropagationTaskExecutor, line 334, the call to > >> getRemoteObject have to be encapsulated into a try- catch body. > >> As you can see, this is not an issue related to the TimeoutException > >> only but it is an issue of the whole propagation process. > >> > >> TimeoutException (or whatever specific propagation exception) won't > >> be never thrown ... > >> > >> Let me take care of this particular fix. > >> > >>> That explains why this test doesn't work. Why it works during the > >>> build? - see topic (2) > >>> > >>> 2. Why UserTestITCase. issueSYNCOPE279() works sometimes. > >>> If UserTestITCase executed after some previous tests (or under > >>> some > >> other conditions: JDK, OS, etc), it throws other exception BEFORE > >> execute the task: > >> > >> This is terrible: why the creation of a new virtual attribute should fail? > >> Doesn't UVirAttr id auto generation work fine anymore? > >> Can you investigate more? > >> > >>> 18:23:41.946 ERROR > >>> org.apache.syncope.core.rest.controller.AbstractController - > >>> Exception thrown by REST methods > >>> org.springframework.dao.DataIntegrityViolationException: The > >>> transaction > >> has been rolled back. See the nested exceptions for details on the > >> errors that occurred.; nested exception is > >> <openjpa-2.2.1-r422266:1396819 fatal store error> > >> org.apache.openjpa.persistence.EntityExistsException: The transaction > >> has been rolled back. See the nested exceptions for details on the errors > that occurred. > >>> FailedObject: > >> org.apache.syncope.core.persistence.beans.user.UVirAttr@cd0cca3 > >>> at > >> > org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAcces > >> sE > >> xceptionIfPossible(EntityManagerFactoryUtils.java:313) ~[spring-orm- > >> 3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPos > >> sible > >> (DefaultJpaDialect.java:121) > >> ~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> > org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransac > >> tionManager.java:517) ~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> org.springframework.transaction.support.AbstractPlatformTransactionMa > >> na > >> ger.processCommit(AbstractPlatformTransactionManager.java:755) > >> ~[spring- tx-3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> org.springframework.transaction.support.AbstractPlatformTransactionMa > >> na > >> ger.commit(AbstractPlatformTransactionManager.java:724) ~[spring-tx- > >> 3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> org.springframework.transaction.interceptor.TransactionAspectSupport. > >> com > >> mitTransactionAfterReturning(TransactionAspectSupport.java:387) > >> ~[spring- tx-3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> org.springframework.transaction.interceptor.TransactionInterceptor.in > >> voke( > >> TransactionInterceptor.java:120) ~[spring-tx- > >> 3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( > >> ReflectiveMethodInvocation.java:172) ~[spring-aop- > >> 3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at > >> > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDyna > >> micAopProxy.java:204) ~[spring-aop-3.2.1.RELEASE.jar:3.2.1.RELEASE] > >>> at $Proxy137.create(Unknown Source) ~[na:na] > >>> at > >> org.apache.syncope.core.rest.controller.UserController.createInternal > >> (User > >> Controller.java:306) ~[UserController.class:na] > >>> at > >> org.apache.syncope.core.rest.controller.UserController.create(UserCon > >> troll > >> er.java:284) ~[UserController.class:na] > >>> > >>> Caused by: org.apache.openjpa.persistence.EntityExistsException: > >> Eindeutiger Index oder Primärschlüssel verletzt: "PRIMARY_KEY_C4 ON > >> PUBLIC.UVIRATTR(ID)" > >>> Unique index or primary key violation: "PRIMARY_KEY_C4 ON > >> PUBLIC.UVIRATTR(ID)"; SQL statement: > >>> INSERT INTO PUBLIC.UVirAttr (ID, OWNER_ID, VIRTUALSCHEMA_NAME) > >> VALUES > >>> (?, ?, ?) [23505-170] {prepstmnt 2122205967 INSERT INTO > >>> PUBLIC.UVirAttr (ID, OWNER_ID, VIRTUALSCHEMA_NAME) VALUES (?, > ?, > >> ?)} > >>> [code=23505, state=23505] > >>> > >>> DataIntegrityViolationException is mapped to > >> SyncopeClientCompositeError Type header in syncopeClientError.jsp and > >> interpreted as SCCEE on the client side. Test is green just because this > effect. > >>> I think the reason of this DataIntegrityViolationException is AUTO > >> generation strategy in AbstractVirtualAttribute entity. > >>> > >>> It seems that this test runs successfully only occasionally because > >>> of > >> another error. > >>> Could you confirm my findings? > >>> > >>> If yes, we should fix the following: > >>> 1. Map TimeoutException to SCCEE > >>> 2. Fix DataIntegrityViolationException for AbstractVirtualAttribute > >>> > >>> Generally I would propose to design integration tests as independent > >>> as > >> possible. Dependencies between different test cases and individual > >> tests makes error analyse extreme difficult and time consuming. > >> Ideally integration test should leave environment unchanged or > compensated. > >>> WDYT? > >>> > >>> Regards, > >>> Andrei. > >>> > >>>> -----Original Message----- > >>>> From: Fabio Martelli [mailto:fabio.marte...@gmail.com] > >>>> Sent: Montag, 28. Januar 2013 16:42 > >>>> To: dev@syncope.apache.org > >>>> Subject: Re: [Question] Problem with test > >>>> UsertTestITCase.issueSYNCOPE279 > >>>> > >>>> Hi Andrei, answers and comment inline. > >>>> > >>>> Il giorno 28/gen/2013, alle ore 16.09, Andrei Shakirin ha scritto: > >>>> > >>>>> Hi, > >>>>> > >>>>> I am analysing problem regarding > UsertTestITCase.issueSYNCOPE279(). > >>>>> It is reproducible in following situations: > >>>>> > >>>>> 1) Run it as single test: mvn -Pdev -DwaitForCheck=false -Dit.test= > >>>> UserTestITCase# issueSYNCOPE279 > >>>> > >>>> Wow, strange, I implemented using these options ... > >>>> > >>>>> Because of some reasons this test is succeed in case if > >>>> > >> > AuthenticationTestITCase,ResourceTestITCase,RoleTestITCase,SchemaTest > >>>> IT Case,UserRequestTestITCase were executed before (interesting :) > >>>> ) > >>>> > >>>> This is really strange. issueSYNCOPE279 shouldn't have any > dependency. > >>>> Please, take a look at the code: it simply create a new profile > >>>> giving it an ad- hoc resource (never used before). > >>>> > >>>>> 2) If all core integration tests is running under JDK 1.7 > >>>>> 3) With some other conditions. > >>>>> > >>>>> My analysis shows that the end reason is that SOAP connector > >>>>> (using CXF > >>>> client) receives HTML as response for test() invocation: > >>>>> > >>>>> 15:47:46.041 DEBUG > >>>> org.identityconnectors.framework.api.operations.GetApiOp.getObject > >>>> Exception: > >>>>> javax.xml.ws.soap.SOAPFaultException: Response was of unexpected > >>>> text/html ContentType. Incoming portion of HTML stream: OK > >>>>> at > >>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java: > >>>> 15 > >>>> 6) ~[cxf-rt-frontend-jaxws-2.7.0.jar:2.7.0] > >>>>> at $Proxy196.checkAlive(Unknown Source) ~[na:na] > >>>>> at > >>>> > >> > org.connid.bundles.soap.WebServiceConnection.test(WebServiceConnectio > >>>> n.java:89) ~[na:na] > >>>>> at > >>>> > >> > org.connid.bundles.soap.WebServiceConnector.checkAlive(WebServiceCon > >>>> nector.java:169) ~[na:na] > >>>>> at > >>>> > org.identityconnectors.framework.impl.api.local.ConnectorPoolManage > >>>> r$ > >>>> Co > >>>> nnectorPoolHandler.testObject(ConnectorPoolManager.java:105) > >>>> ~[framework-internal-1.3.2.jar:na] > >>>> > >>>> This exception occurs after the Timeout. It is thrown by the "zombie" > task. > >>>> > >>>>> Therefore propagation of resource "ws-target-resource-3" is failed > >>>>> with > >>>> following error: > >>>>> > >>>>> 15:46:55.221 ERROR > >>>> > >> > org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecu > >>>> to r - Exception during provision on resource ws-target-resource-3 > >>>>> org.apache.syncope.core.propagation.TimeoutException: Request > >> timeout > >>>>> at > >>>> > >> > org.apache.syncope.core.propagation.impl.ConnectorFacadeProxy.getObje > >>>> c > >>>> t(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na] > >>>>> at > >>>> > >> > org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecu > >>>> to > >>>> r.getRemoteObject(AbstractPropagationTaskExecutor.java:438) > >>>> ~[AbstractPropagationTaskExecutor.class:na] > >>>>> at > >>>> > >> > org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecu > >>>> to > >>>> r.execute(AbstractPropagationTaskExecutor.java:288) > >>>> ~[AbstractPropagationTaskExecutor.class:na] > >>>> > >>>> This is the expected exception: it should be handled and returned > >>>> as a SyncopeClientErrorException. > >>>> > >>>>> Could you give a hint how to investigate this connector invocation > error? > >>>>> To which instance SOAP connector sends test() request? Why it > >>>>> sometimes > >>>> answers with HTML? > >>>> > >>>> It is not a really soap resource: it is a servlet returning "OK" > >>>> after a delay of 60 seconds. > >>>> Syncope shouldn't take care of the result because it comes after > >>>> the > >> timeout. > >>>> > >>>> Regards, > >>>> F. > >>>> > >>>> > >>> > >
