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.convertJpaAccessE >> xceptionIfPossible(EntityManagerFactoryUtils.java:313) ~[spring-orm- >> 3.2.1.RELEASE.jar:3.2.1.RELEASE] >>> at >> org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible >> (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.AbstractPlatformTransactionMana >> ger.processCommit(AbstractPlatformTransactionManager.java:755) ~[spring- >> tx-3.2.1.RELEASE.jar:3.2.1.RELEASE] >>> at >> org.springframework.transaction.support.AbstractPlatformTransactionMana >> 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.invoke( >> 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(UserControll >> 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.ConnectorPoolManager$ >>>> 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. >>>> >>>> >>> >
