You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Andrei Shakirin <as...@talend.com> on 2013/01/28 16:09:42 UTC
[Question] Problem with test UsertTestITCase.issueSYNCOPE279
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
Because of some reasons this test is succeed in case if AuthenticationTestITCase,ResourceTestITCase,RoleTestITCase,SchemaTestITCase,UserRequestTestITCase were executed before (interesting :) )
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:156) ~[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(WebServiceConnection.java:89) ~[na:na]
at org.connid.bundles.soap.WebServiceConnector.checkAlive(WebServiceConnector.java:169) ~[na:na]
at org.identityconnectors.framework.impl.api.local.ConnectorPoolManager$ConnectorPoolHandler.testObject(ConnectorPoolManager.java:105) ~[framework-internal-1.3.2.jar:na]
Therefore propagation of resource "ws-target-resource-3" is failed with following error:
15:46:55.221 ERROR org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor - 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.getObject(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na]
at org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor.getRemoteObject(AbstractPropagationTaskExecutor.java:438) ~[AbstractPropagationTaskExecutor.class:na]
at org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor.execute(AbstractPropagationTaskExecutor.java:288) ~[AbstractPropagationTaskExecutor.class:na]
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?
Regards,
Andrei.
RE: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
Posted by Andrei Shakirin <as...@talend.com>.
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.martelli@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.1000906@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.martelli@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.martelli@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.
> >>>>
> >>>>
> >>>
> >
Re: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
Posted by Fabio Martelli <fa...@gmail.com>.
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.1000906@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.martelli@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.martelli@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.
>>>>
>>>>
>>>
>
Re: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
Posted by Fabio Martelli <fa...@gmail.com>.
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.convertJpaAccessExceptionIfPossible(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(JpaTransactionManager.java:517) ~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:755) ~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:724) ~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(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(JdkDynamicAopProxy.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(UserController.java:306) ~[UserController.class:na]
> at org.apache.syncope.core.rest.controller.UserController.create(UserController.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.martelli@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,SchemaTestIT
>> 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:156)
>> ~[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.AbstractPropagationTaskExecuto
>> 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.getObjec
>> t(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na]
>>> at
>> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
>> r.getRemoteObject(AbstractPropagationTaskExecutor.java:438)
>> ~[AbstractPropagationTaskExecutor.class:na]
>>> at
>> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
>> 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.
>>
>>
>
RE: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
Posted by Andrei Shakirin <as...@talend.com>.
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.
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:
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.convertJpaAccessExceptionIfPossible(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(JpaTransactionManager.java:517) ~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:755) ~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:724) ~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(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(JdkDynamicAopProxy.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(UserController.java:306) ~[UserController.class:na]
at org.apache.syncope.core.rest.controller.UserController.create(UserController.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.martelli@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,SchemaTestIT
> 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:156)
> ~[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.AbstractPropagationTaskExecuto
> 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.getObjec
> t(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na]
> > at
> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
> r.getRemoteObject(AbstractPropagationTaskExecutor.java:438)
> ~[AbstractPropagationTaskExecutor.class:na]
> > at
> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
> 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.
>
>
Re: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
Posted by Fabio Martelli <fa...@gmail.com>.
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,SchemaTestITCase,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:156) ~[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(WebServiceConnection.java:89) ~[na:na]
> at org.connid.bundles.soap.WebServiceConnector.checkAlive(WebServiceConnector.java:169) ~[na:na]
> at org.identityconnectors.framework.impl.api.local.ConnectorPoolManager$ConnectorPoolHandler.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.AbstractPropagationTaskExecutor - 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.getObject(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na]
> at org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor.getRemoteObject(AbstractPropagationTaskExecutor.java:438) ~[AbstractPropagationTaskExecutor.class:na]
> at org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor.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.