JTA timeout setting

hi,
I am using Jdeveloper 11.1.1.5. Is there an option where i can set the JTA Timeout for the integrated WLS server.
I know how to do it using the Web Console, however Id like to be able to do it either from a Jdeveloper setting or maybe a configuration file.
Any help is much appreciated.
Thanks

I presume you are using EJB as the model layer here.
Check in weblogic-ejb-jar.xml for the entry that allows us to control the timeout paremeter.
<transaction-descriptor>
<trans-timeout-seconds>60</trans-timeout-seconds> </transaction-descriptor>
You will need to check if it overrides the timeout on the WLS console

Similar Messages

  • JDBC / JTA Timeouts : How to set a timeout on the fetching of a query ?

    Hi !
    I'm working on an Application running on Weblogic Server 11g. This app executes a query on an Oracle 11g database ...
    The problem is that this query returns millions of records ... and the app fetches the results during tens of minutes.
    We would like to set a timeout, wich will abandon the transaction, hang the database connection, destroy the socket ... or anything else ...
    This timeout will prevent the thread to become in STUCK state and stucking the weblogic managed server.
    Is this possible ?
    Thank's for your answers.
    Steve.
    Edited by: 966918 on 10 avr. 2013 07:18

    Abandon timeout will not help. That is only used if a database crashes during the second phase of commit. It specifies how long the transaction manager should keep trying to complete the transaction.
    JTA timeout will only work if you are using XA datasources and two-phase commit transactions. When the timeout occurs, it guarantees that the transaction cannot be committed. Eventually, all of the participant resources will be notified and will not allow any more work to take place on the transaction. It does not stop the threads and the application must be written to handle exceptions appropriately.
    Edited by: Steve Felts on Apr 17, 2013 8:32 AM

  • Weblogic JTA timeout and PreparedStatement cache problem (Closed Statement)

    Hello,
    I am facing up a problem using a Weblogic connection pool with a PreparedStatement.
    Here is the environement :
    - Weblogic application server 10.3
    - JDBC connection pool with Oracle Thin driver (from server library) - all parameters by default i.e. StatementCache size = 10
    - JTA transaction timeout = 30s
    The problem is : if a prepared statement ends because of a JTA timeout, I receive the following stack exception/ stack trace
    java.sql.SQLException: The transaction is no longer active - status: 'Rolling Back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 33 seconds
    BEA1-000D8AE7230EFAA3EDC9]'. No further JDBC access is allowed within this transaction.
    at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:178)
    at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:188)
    at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:92)
    at weblogic.jdbc.wrapper.Connection.clearCachedStatement(Connection.java:814)
    at weblogic.jdbc.wrapper.PreparedStatement.clearCachedStatement(PreparedStatement.java:1357)
    and then, if we try to re-execute immediately the same operation (*same statement* but new request, new thread, new JTA transaction ...) we receive without delay the following exception :
    java.sql.SQLException: Closed Statement
    at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
    at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:403)
    It seems like a bug in the caching mechanism of Weblogic, the 1st stack trace shows method from the statement cache implementation, I presume weblogic is trying the clear the statement from the cache after the iniitial TimedOutException (SQLException), but as the JDBC connection is unusable at this point, the clearing fails and the statement remains in the cache but is physically closed by JDBC.
    1st question, why weblogic does need to call JTSConnection.checkConnection() for clearing a statement from its internal cache, it is a pure java memory operation isnt'it ?
    2nd question : How to solve the problem without setting the StatementCache size to 0 (I tried, it solves the problem)? I don't want to disable completely the Weblogic statement caching, I have a small PreparedStatement called very frequently.
    Thanks for any help

    The main issue is that the transactional context that is supposed to underlay the JDBC code being executed,
    has gone away. Indeed, any DBMS changes that may have been made by your code so far, have been rolled
    back and are gone. Your code should not be trying to continue JDBC as normal, and WebLogic is trying to stop
    you. The control flow should go back up to the location where the transaction was initiated, so as to restart from
    the beginning if that is what is desired, including getting a new JDBC connection and remaking all the statements
    etc.
    HTH,
    Joe
    Edited by: Joe Weinstein on Dec 3, 2010 9:12 AM

  • Timeout setting in setup package server

    Hi All,
    We wanted to change the time out setting in our Middleware server(Windows platform wintel) from present 120 mins to 180 mins which is used for creation of setup package.Where we can change the timeout setting in server.Please give me the path or location ..
    Thanks in advance
    Devendra

    Hi,
    I am not sure about the native Jboss JTA, but in general the following is true:
    -the transaction timeout determines when 'pending' transactions are cleaned up by the JTA
    -the larger the value, the longer the time that such transactions can be around
    The performance impact depends on the particularities of your application and server environment; to name a few:
    -For hot-spot data in your database, transactions will normally have to wait longer to get locks held by other transactions. If the timeout is too short then the clients will see many requests fail because the underlying transaction will timeout before the locks are gotten, and the JTA will rollback.
    -On the other hand, if (for some reason) you have failing requests that leave active transactions floating in the server, then a larger timeout will mean that such floating transactions will not release their locks yet (happens at rollback/commit only). So here a larger timeout means that lost transactions (that will rollback anyway) will prevent other transactions from doing business.
    -The same argument holds for deadlocks. If a transaction is involved in a deadlock situation then the deadlock will not be resolved until the transaction rolls back after timeout. In this case too, the other transactions are hindered by the locks of a 'lost' transaction.
    As a rule of thumb, I would say: keep transaction timeout as high as necessary to allow most transactions to get 'useful' locks (but not much higher than that). For instance, you could measure the statistics on response times under realistic loads and base your timeout value on that (if you're not measuring the deadlocks of course).
    Best,
    Guy
    http://www.atomikos-support.com:8080/forums -- Java/J2EE/JTA Transactions Forum

  • Can anyone clear me about XATransactionTimeout and JTA timeout ?

    I set JTA timeout seconds to 180 from WLS Admin Conosle.
    If I set XASetTransactionTimeout="false" what transaction timeout value that used at this option ?
    And if I set XASetTransactionTimeout="true" and set XATransactionTimeout="0" to JDBC XA pool what transaction timeout value that used in this case ?
    And the last if I set XASetTransactionTimeout="true" and set XATransactionTimeout="100" to JDBC XA pool what transaction timeout value that used in this case ?
    thank you for your advise.
    Sutep

    hi
    sorry for that,here is the link
    http://help.sap.com/saphelp_crm60/helpdata/en/dd/6e133b3f618442e10000000a114084/frameset.htm
    best regards
    ashish

  • JTA timeout value doesn't take effect within stateful EJB

    Platform : weblogic10.3.5
    problem description: I have 2 ejbs: ejb1 is a stateful bean and the transaction is bean managed, the trans-timeout-seconds is set to 60; ejb2 is a stateless bean, transaction is container managed, transaction type is required, trans-timeout-seconds is 35. And the JTA timeout value set in weblogic console is 20.
    ejb1 invokes the ejb2's interface to access db, and this transaction should be committed since ejb2 is container managed transaction. Then ejb1 create userTransaction to access db. And I found the transaction will be timed out after 35 seconds, which is the trans-timeout-seconds of ejb2.
    Here is the sample code
    ejb1.method(){
         ejb2.method();
         try{
              Context ctx = new InitialContext();
              UserTransaction ut = (UserTransaction) ctx.lookup(USER_TRANSACTION_REF_NAME);
              ut.begin();
                   //do some operation
              ut.commit();
         }catch(Exception e){
                   try{
              ut.rollback();
                   }catch(Exception ee){
    Is timeout value of the user transaction created in ejb1 should be jta timeout 20? why the ejb2's trans-timeout-seconds affects the ejb1's usertransaction timeout value? does any body know the reason?
    Thanks

    A transaction timeout will not and cannot terminate user code as there
    is no Java API for doing so. If you wish the user code to timeout, try
    using the "setQueryTimeout()" method on the SQL statement. The WebLogic
    JTS will timeout the transaction using another thread and will prevent
    any JDBC activity associated with the global transaction from being
    commited.
    Sincerely,
    Charlie Therit
    Developer Relations Engineer
    BEA Support
    hjkuob wrote:
    "Dear Support,
    We encounter problems with transaction timeout and details as follows:
    A swing UI calls a session bean in which a DAO(Data Access Object) is invoked,
    In this DAO, it try to invoke a store procedure like following :
    dateSource = getTxDataSource();
    conn = (Connection)dataSource.getConnection();
    cstmt = conn.prepareCall("{call PK_AP_OO_CATCH_UP.P_AP_MAIN(?,?) }");
    cstmt.registerOutParameter(...........);
    cstmt.execute();
    When a irrevalent guy carelessly locked the table , the swing keep running for 5 hours and
    the transaction never throws exception ( both JTA and trans-timeout-seconds are set).
    I've also survey docments , however, we are not sure about the definition of Container-managed transactions
    and Bean-managed transactions. So there are two problems to be solved :
    1. How to solve the timeout problem as the sample code above for calling store procedures,
    and what kind of transctions it uses according to the definition ?
    2. If a normal sql statement is executed as follows , should we declare explicit transaction ( begin and commit) ? %

  • Xl Reporter Timeout Setting

    Hi All
    We have the following message when trying to generate a large report in XL Reporter. 
    An error occurred while Executing report!
    Decription: Rows 2358, Column 244
    Timeout expired
    This is a very large report and it times out before it completes.  This message comes up after approximately 20 minutes of running.
    Please can anyone advise asap if they are aware of a timeout setting that can be extended in XL Reporter. 
    Alternatively is there a fixed limitation in the number of rows or the time a report is allowed to run?
    Kind regards
    Sam Burchell

    Hi Sam Burchell,
    When XLR builts report, it need both disk space and memories. For such large report, I doubt you have anyway to run. You need to redesign the report or add parameter to restrict the data range.
    For a report with over 200 columns, how would user read it?
    You can calculate by yourself: 2358 X 244 (cells) is probably the limit for this specific environment
    Thanks,
    Gordon

  • CatchAll block not catching JTA timeout with XA datasource

    Hi,
    We have a synchronous BPEL process with DB Adapters calling XA datasource. We configured a CatchAll block to catch any exception that may arise during the execution. JTA timeout is 5 min (300s). DB Adapter calls a procedure in which we have introduced delay using DBMS Lock API.
    Whenever the total invoke activities timeout is greater than 5min, JTA exception is occurring, but not getting caught in CatchAll block.
    Below is the log
    Error Message: {http://schemas.oracle.com/bpel/extension}runtimeFault
    Fault ID default/OnAlarmTest!2.0*soa_93bf9d67-975e-4998-b725-9c68903cd40f/BPELProcess1/818062-BpInv1-BpSeq0.3-3
    Fault Time Jan 6, 2015 6:04:12 PM
    Non Recoverable System Fault :
    <bpelFault><faultType>0</faultType><runtimeFault xmlns="http://schemas.oracle.com/bpel/extension"><part name="summary"><summary>Global retry rollback fault thrown. The current JTA transaction is aborting due to an user rollback fault being thrown. The upstream component should retry in a new JTA transaction upon catching this fault. This exception was caused by a global retry fault being thrown from downstream component. The user had directed the BPEL engine to roll back the current JTA transaction and retry within new JTA transactions for the specified number of times and retry interval. There is no action recommended. </summary></part><part name="detail"><detail>ORABPEL-02198 Global retry rollback fault thrown. The current JTA transaction is aborting due to an user rollback fault being thrown. The upstream component should retry in a new JTA transaction upon catching this fault. This exception was caused by a global retry fault being thrown from downstream component. The user had directed the BPEL engine to roll back the current JTA transaction and retry within new JTA transactions for the specified number of times and retry interval. There is no action recommended. at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:336) at com.collaxa.cube.engine.ext.common.InvokeHandler.__invoke(InvokeHandler.java:1099) at com.collaxa.cube.engine.ext.common.InvokeHandler.handleNormalInvoke(InvokeHandler.java:594) at com.collaxa.cube.engine.ext.common.InvokeHandler.handle(InvokeHandler.java:132) at com.collaxa.cube.engine.ext.bpel.common.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:74) at com.collaxa.cube.engine.ext.bpel.common.wmp.BaseBPELActivityWMP.perform(BaseBPELActivityWMP.java:173) at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:2718) at com.collaxa.cube.engine.CubeEngine._handleWorkItem(CubeEngine.java:1197) at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1100) at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:76) at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:251) at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:330) at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4652) at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4583) at com.collaxa.cube.engine.CubeEngine._createAndInvoke(CubeEngine.java:714) at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:559) at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.createAndInvoke(CubeEngineBean.java:103) at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.syncCreateAndInvokeParticipate(CubeEngineBean.java:181) at sun.reflect.GeneratedMethodAccessor1631.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at com.oracle.pitchfork.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:103) at oracle.security.jps.ee.ejb.JpsAbsInterceptor$1.run(JpsAbsInterceptor.java:113) at java.security.AccessController.doPrivileged(Native Method) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:324) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.runJaasMode(JpsAbsInterceptor.java:100) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.intercept(JpsAbsInterceptor.java:154) at oracle.security.jps.ee.ejb.JpsInterceptor.intercept(JpsInterceptor.java:113) at sun.reflect.GeneratedMethodAccessor1095.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.oracle.pitchfork.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:68) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.oracle.pitchfork.spi.MethodInvocationVisitorImpl.visit(MethodInvocationVisitorImpl.java:34) at weblogic.ejb.container.injection.EnvironmentInterceptorCallbackImpl.callback(EnvironmentInterceptorCallbackImpl.java:54) at com.oracle.pitchfork.spi.EnvironmentInterceptor.invoke(EnvironmentInterceptor.java:42) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy311.syncCreateAndInvokeParticipate(Unknown Source) at com.collaxa.cube.engine.ejb.impl.bpel.BPELEngineBean_51369e_ICubeEngineLocalBeanImpl.__WL_invoke(Unknown Source) at weblogic.ejb.container.internal.SessionLocalMethodInvoker.invoke(SessionLocalMethodInvoker.java:39) at com.collaxa.cube.engine.ejb.impl.bpel.BPELEngineBean_51369e_ICubeEngineLocalBeanImpl.syncCreateAndInvokeParticipate(Unknown Source) at com.collaxa.cube.engine.delivery.DeliveryHandler.callCreateAndInvoke(DeliveryHandler.java:914) at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequestAnyType(DeliveryHandler.java:631) at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequest(DeliveryHandler.java:565) at com.collaxa.cube.engine.delivery.DeliveryHandler.request(DeliveryHandler.java:238) at com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.request(CubeDeliveryBean.java:541) at sun.reflect.GeneratedMethodAccessor1630.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at com.oracle.pitchfork.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:103) at oracle.security.jps.ee.ejb.JpsAbsInterceptor$1.run(JpsAbsInterceptor.java:113) at java.security.AccessController.doPrivileged(Native Method) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:324) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.runJaasMode(JpsAbsInterceptor.java:100) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.intercept(JpsAbsInterceptor.java:154) at oracle.security.jps.ee.ejb.JpsInterceptor.intercept(JpsInterceptor.java:113) at sun.reflect.GeneratedMethodAccessor1095.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.oracle.pitchfork.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:68) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.oracle.pitchfork.spi.MethodInvocationVisitorImpl.visit(MethodInvocationVisitorImpl.java:34) at weblogic.ejb.container.injection.EnvironmentInterceptorCallbackImpl.callback(EnvironmentInterceptorCallbackImpl.java:54) at com.oracle.pitchfork.spi.EnvironmentInterceptor.invoke(EnvironmentInterceptor.java:42) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy307.request(Unknown Source) at com.collaxa.cube.engine.ejb.impl.bpel.BPELDeliveryBean_5k948i_ICubeDeliveryLocalBeanImpl.__WL_invoke(Unknown Source) at weblogic.ejb.container.internal.SessionLocalMethodInvoker.invoke(SessionLocalMethodInvoker.java:39) at com.collaxa.cube.engine.ejb.impl.bpel.BPELDeliveryBean_5k948i_ICubeDeliveryLocalBeanImpl.request(Unknown Source) at oracle.fabric.CubeServiceEngine.request(CubeServiceEngine.java:458) at oracle.integration.platform.blocks.mesh.SynchronousMessageHandler.doRequest(SynchronousMessageHandler.java:139) at oracle.integration.platform.blocks.mesh.MessageRouter.request(MessageRouter.java:182) at oracle.integration.platform.blocks.mesh.MeshImpl.request(MeshImpl.java:190) at sun.reflect.GeneratedMethodAccessor1570.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at oracle.integration.platform.metrics.PhaseEventAspect.invoke(PhaseEventAspect.java:59) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy325.request(Unknown Source) at oracle.integration.platform.blocks.soap.WebServiceEntryBindingComponent.doMessageProcessing(WebServiceEntryBindingComponent.java:1636) at oracle.integration.platform.blocks.soap.WebServiceEntryBindingComponent.processIncomingMessage(WebServiceEntryBindingComponent.java:1016) at oracle.integration.platform.blocks.soap.FabricProvider.processMessage(FabricProvider.java:113) at oracle.j2ee.ws.server.provider.ProviderProcessor.doEndpointProcessing(ProviderProcessor.java:1187) at oracle.j2ee.ws.server.WebServiceProcessor.invokeEndpointImplementation(WebServiceProcessor.java:1123) at oracle.j2ee.ws.server.provider.ProviderProcessor.doRequestProcessing(ProviderProcessor.java:581) at oracle.j2ee.ws.server.WebServiceProcessor.processRequest(WebServiceProcessor.java:235) at oracle.j2ee.ws.server.WebServiceProcessor.doService(WebServiceProcessor.java:195) at oracle.j2ee.ws.server.WebServiceServlet.doPost(WebServiceServlet.java:487) at oracle.integration.platform.blocks.soap.FabricProviderServlet.doPost(FabricProviderServlet.java:523) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119) at java.security.AccessController.doPrivileged(Native Method) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:324) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:460) at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103) at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171) at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:163) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256) at weblogic.work.ExecuteThread.run(ExecuteThread.java:221) Caused by: oracle.fabric.common.FabricInvocationException: BINDING.JCA-12563 Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'test1' failed due to: Stored procedure invocation error. Error while trying to prepare and execute the HR.PROC_DELAY1 API. An error occurred while preparing and executing the HR.PROC_DELAY1 API. Cause: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation ORA-06512: at "SYS.DBMS_LOCK", line 201 ORA-06512: at "HR.PROC_DELAY1", line 7 ORA-06512: at line 1 Check to ensure that the API is defined in the database and that the parameters match the signature of the API. This exception is considered retriable, likely due to a communication failure. Because the global transaction is rolling back the invoke must be retried in a new transaction, restarting from the place of the last transaction commit. To classify it as non-retriable instead add property nonRetriableErrorCodes with value "1013" to your deployment descriptor (i.e. weblogic-ra.xml). ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. at oracle.integration.platform.blocks.adapter.fw.jca.cci.EndpointInteractionException.getFabricInvocationException(EndpointInteractionException.java:75) at oracle.integration.platform.blocks.adapter.AdapterReference.getFabricInvocationException(AdapterReference.java:316) at oracle.integration.platform.blocks.adapter.AdapterReference.request(AdapterReference.java:219) at oracle.integration.platform.blocks.mesh.SynchronousMessageHandler.doRequest(SynchronousMessageHandler.java:139) at oracle.integration.platform.blocks.mesh.MessageRouter.request(MessageRouter.java:182) at oracle.integration.platform.blocks.mesh.MeshImpl.request(MeshImpl.java:190) at sun.reflect.GeneratedMethodAccessor1570.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at oracle.integration.platform.metrics.PhaseEventAspect.invoke(PhaseEventAspect.java:71) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy325.request(Unknown Source) at oracle.fabric.CubeServiceEngine.requestToMesh(CubeServiceEngine.java:858) at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:267) ... 146 more Caused by: BINDING.JCA-12563 Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'test1' failed due to: Stored procedure invocation error. Error while trying to prepare and execute the HR.PROC_DELAY1 API. An error occurred while preparing and executing the HR.PROC_DELAY1 API. Cause: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation ORA-06512: at "SYS.DBMS_LOCK", line 201 ORA-06512: at "HR.PROC_DELAY1", line 7 ORA-06512: at line 1 Check to ensure that the API is defined in the database and that the parameters match the signature of the API. This exception is considered retriable, likely due to a communication failure. Because the global transaction is rolling back the invoke must be retried in a new transaction, restarting from the place of the last transaction commit. To classify it as non-retriable instead add property nonRetriableErrorCodes with value "1013" to your deployment descriptor (i.e. weblogic-ra.xml). ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. at oracle.integration.platform.blocks.adapter.fw.jca.cci.JCAInteractionInvoker.executeJcaInteraction(JCAInteractionInvoker.java:486) at oracle.integration.platform.blocks.adapter.fw.jca.cci.JCAInteractionInvoker.invokeJcaReference(JCAInteractionInvoker.java:572) at oracle.integration.platform.blocks.adapter.fw.jca.cci.JCAInteractionInvoker.invokeSyncJcaReference(JCAInteractionInvoker.java:545) at oracle.integration.platform.blocks.adapter.fw.jca.cci.JCAEndpointInteraction.performSynchronousInteraction(JCAEndpointInteraction.java:547) at oracle.integration.platform.blocks.adapter.AdapterReference.request(AdapterReference.java:179) ... 161 more Caused by: BINDING.JCA-11811 Stored procedure invocation error. Error while trying to prepare and execute the HR.PROC_DELAY1 API. An error occurred while preparing and executing the HR.PROC_DELAY1 API. Cause: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation ORA-06512: at "SYS.DBMS_LOCK", line 201 ORA-06512: at "HR.PROC_DELAY1", line 7 ORA-06512: at line 1 Check to ensure that the API is defined in the database and that the parameters match the signature of the API. This exception is considered retriable, likely due to a communication failure. Because the global transaction is rolling back the invoke must be retried in a new transaction, restarting from the place of the last transaction commit. To classify it as non-retriable instead add property nonRetriableErrorCodes with value "1013" to your deployment descriptor (i.e. weblogic-ra.xml). at oracle.tip.adapter.db.exceptions.DBResourceException.createXARetriableException(DBResourceException.java:686) at oracle.tip.adapter.db.exceptions.DBResourceException.createEISException(DBResourceException.java:658) at oracle.tip.adapter.db.sp.SPUtil.createResourceException(SPUtil.java:180) at oracle.tip.adapter.db.sp.AbstractStoredProcedure.execute(AbstractStoredProcedure.java:131) at oracle.tip.adapter.db.sp.SPInteraction.executeStoredProcedure(SPInteraction.java:142) at oracle.tip.adapter.db.DBInteraction.executeStoredProcedure(DBInteraction.java:1167) at oracle.tip.adapter.db.DBInteraction.execute(DBInteraction.java:254) at oracle.integration.platform.blocks.adapter.fw.jca.cci.JCAInteractionInvoker.executeJcaInteraction(JCAInteractionInvoker.java:357) ... 165 more Caused by: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation ORA-06512: at "SYS.DBMS_LOCK", line 201 ORA-06512: at "HR.PROC_DELAY1", line 7 ORA-06512: at line 1 at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:462) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405) at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:931) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:481) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:205) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:548) at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:213) at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:1111) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1488) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3769) at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3954) at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:9353) at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1539) at weblogic.jdbc.wrapper.PreparedStatement.execute(PreparedStatement.java:99) at oracle.tip.adapter.db.sp.AbstractStoredProcedure.execute(AbstractStoredProcedure.java:123) ... 169 more </detail></part><part name="code"><code>com.collaxa.cube.engine.EngineException</code></part></runtimeFault></bpelFault>
    Request your suggestions/ pointers on this.
    Environment details
    SOA 11.1.1.7.0.
    Weblogic 10.3.6
    Oracle EE 11.2.0.1.0
    Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
    Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
    OS: Windows Server 2008R2 Enterprise
    Many thanks in advance.
    Sai

    You can use the SOA Fault Management Framework to capture this error and handle it accordingly.  Use a <test> condition in the fault policy file to test for the specific $fault values you're getting in this error and then link to what you need to execute to handle the error in the corresponding <action> element. In the fault binding file bind this aforementioned fault policy to the DB Adapter reference component via the <reference> element. Alternatively you could bind it to the composite if the test condition is sufficiently detailed enough.
    Hope it helps.

  • Samplerate problem using Analog In and Counter In from a NI 6259 USB. "Counter timeout" setting in DAQmx?!

    Hello,
    I got a fundamental problem with the correlation of the timer settings of the DAQmx driver in DIAdem DAQ. I dont know where the problem is located exactly but maybe someone can help me if I explain what happens:
    In my configuration I use some analog inputs from a USB 6259 with 20kHz samplerate and two counter inputs for frequency measuring via DAQmx in DIAdem DAQ.
    There has to be an extra DAQin block for the analog inputs and the counter inputs with also an extra "Clock"-block for each of them. The clock of the analog inputs runs with 20kHz hardware clock and the other one with 10Hz software clock because the hardware clock mode is not allowed or supported.
    My problem is the display refresh rate in VIEW. If the counter signal has no input (because the measured system is not active) the display seems to wait for any input and doesnt refresh the analog values on screen. If the system is active and a rectangle signal is seen by the counter in, the display refresh rate raises and the frequency value is displayed more or less accurate. Has that something to do with the counter timeout setting in the DAQin driver options block (marked in the attached image)? If i decrease the timeout, the display refresh rate gets better but not as good as without using the counter inputs in my DAQ diagram. I think the counter input is not as easy to handle as the usual analog inputs... I only want to see the measured frequency on the display during the measurement without getting any influence on the analog input channels and their displaying.
    The other problem is the display and the measurement of the frequency itself. If i check the function of the counter input in the Meas. & Automation Explorer the frequency is display correct without any dropouts or something like that. The signal I measure in DIAdem on the other side looks quite bad because there are spikes of some MHz and even more although the measured range is between 20 and 80Hz!
    Has anybody made similar experiences?
    Regards
    S. Zimmer
    Attachments:
    probs.png ‏112 KB

    Hi there,
    it seems that german is your mothertongue, so I'll reply on german.
    Digitale Eingänge müssen Software getaktet werden, da nur analoge Eingänge Hardware-Takt Unterstützung haben!
    Sie können den Hardware-Takt nur mit analogen Eingängen einsetzen, die, von einem Timer gesteuert, gepuffert Werte einlesen können. Digitale Größen verarbeitet der Hardware-Takt nicht.
    Mit dem Hardware-Takt erreichen Sie sehr hohe Abtastraten. DIAdem überträgt die gewünschte Rate und die Kanalliste auf die Karte und startet die Messung. Die Hardware erfasst die Daten selbstständig und sammelt die Daten. Der PC ist nur für den Abtransport und die Weiterverarbeitung verantwortlich.[...]
    Da digitale Signale nicht im Hardware-Takt erfasst werden können, müssen diese Signale parallel in Software-Takten ermittelt werden. Dies kann zu zeitlichen Verschiebungen führen, weil sowohl beim Start der Messung als auch während der Messung keine Synchronisierung der Timer im PC und im Messgerät erfolgen kann. Da zwei Timer nie ganz genau gleichzeitig gestartet werden und auch nie ganz genau gleich schnell laufen, stimmen die Zeiten in den Zeitkanälen nach der Messung nicht genau überein. Üblicherweise betragen die Abweichungen einige Millisekunden.[...]
    Weiters hab ich mal n Versuchsaufbau für die Frequenzmessung gemacht. Ich konnte problemlos Frequenzen messen...
    Am besten du schilderst kurz den Aufbau deiner Messung, was du messen möchtest und wie du den Max konfiguriert hast.
    Mfg Markus

  • New-WebServiceProxy timeout setting?

    Hi,
    Is there a way to increase the timeout setting for new-webserviceproxy? I am calling a webservice that takes a some time and my powershell script times out "New-WebServiceproxy : The operation has timed out"
    Thanks

    Hi,
    Change the intellisense timeout value from the default 3 seconds to a greater value.
    To do this, click Tools, and then click Options. On the General Settings tab, in the Intellisense section of the form, click the drop-down list to
    change the Intellisense timeout in seconds value. 
    This works for Windows PowerShell 3.0 ISE. Please try it also with your own powershell.
    In addition, hope the below link be helpful:
    BUG: You receive a "The operation has timed-out" error message when you access a Web service or when you use the IPAddress class
    http://support.microsoft.com/kb/815209
    Regards,
    Yan Li
    Yan Li
    TechNet Community Support

  • Portal Session Timeout Setting

    There is a JServ session and a portal session. I know how to control session timeout and session clean up frequency in JServ - that's in zone.properties. But, I dont know how to set timeout for portal session, i.e., I'd like to have the user be forced to login again when he has been idle for 15 mins - and only if he has been idle. Jserv session settings are not sufficient for this because Portal has it's own session that must time out.
    How to set this timeout value (I'm using my own provider which has a timeout setting in zone.properties and includes a bunch of JSP portlets)? Also, is there a clean up thread for which the frequency has to be set?

    I've contacted metalink weeks ago, and this is NOW, a know bug...
    Incredible... Oracle just DO NOT TEST their products... Even a simple SESSION timeout do not work. Also, if I click back after "I log In and Log out" ... Session still up without have to login again!
    BUG 2442268

  • IIOP timeout setting??

    I have a client that calls an EJB using IIOP through a servlet. It connects fine
    and I can see the bean "working" on the server side. After 60 seconds, the client
    receives the following error:
    java.rmi.MarshalException: CORBA COMM_FAILURE 1 Maybe; nested exception is:
         org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: Maybe
    org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: Maybe
         at com.sun.corba.se.internal.iiop.IIOPConnection.purge_calls(IIOPConnection.java:785)
         at com.sun.corba.se.internal.iiop.ReaderThread.run(IIOPConnection.java:118)
    However the bean is unaffected and completes its processing later. It does get
    an exception when trying to send the result back to the client. It seems that
    there is an IIOP timeout setting that needs to set higher in this case and the
    default is approximately 60 seconds. Any suggestions?
    Thanks in advance.
    -geoff.

    andy,
    you mean as another attribute somewhere in config.xml? please specify how to
    go about configuring this.
    -geoff.
    Andy Piper <[email protected]> wrote:
    "Geoff" <[email protected]> writes:
    I have a client that calls an EJB using IIOP through a servlet. Itconnects fine
    and I can see the bean "working" on the server side. After 60 seconds,the client
    receives the following error:
    java.rmi.MarshalException: CORBA COMM_FAILURE 1 Maybe; nested exceptionis:
         org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: Maybe
    org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: Maybe
         at com.sun.corba.se.internal.iiop.IIOPConnection.purge_calls(IIOPConnection.java:785)
         at com.sun.corba.se.internal.iiop.ReaderThread.run(IIOPConnection.java:118)
    However the bean is unaffected and completes its processing later.It does get
    an exception when trying to send the result back to the client. Itseems that
    there is an IIOP timeout setting that needs to set higher in this caseand the
    default is approximately 60 seconds. Any suggestions?There is an undocumented property on the Server MBean:
    IdleIIOPConnectionTimeout
    which you can configure in seconds to fix this. Unfortunately the JDK
    Orb is particularly bad at connection management which is why we had
    to do this. With 1.4 we can do somewhat better since we can use
    CloseConnection to tell the client to gracefully shutdown. We have
    revamped some of this also in WLS 7.0 so that the default timeout is
    longer for pending requests (as opposed to idle connections).
    andy

  • HTTP Connection timeout setting

    Hi,
    I'm using ebXML protocol for B2B 10.1.2.3+MLR 5.
    I talk to multiple trading partners and when one of the TP is down, we see that there is a pileup of messages in the backend queues.
    This is because, there is constant message inflow into the JMS queues by the back-end application and each message is taking a long time to timeout (nearly 20 seconds). So what effectively happens is that a message was supposed to reach the TP in 1 sec will take 20 sec before it labels as a HTTP connection timeout error .
    Can we set the HTTP Connection timeout setting in B2B? (I saw a setting in B2BGurus for EDI though)
    If not, please can you suggest if it can be set in the Application Server level?
    Please help!
    Thanks in advance,
    Warm Regards,
    Suhas.

    All,
    At the application server level, there is a timeout setting in httpd.conf. The default value has been set to 300 seconds.
    Regards,
    Suhas.

  • Timeout setting for Realtime-Sequence execution

    Hello,
    I'm referring to the "Timeout" setting in the stimulus profile editor or the "Timeout" parameter of the SequenceCallInfo Constructor. The description of this parameter is as follows:
    The timeout in milliseconds within which the sequence must complete each time step.
    What exactly is this parameter good for? I understand that each task in a realtime sequence is executed once per PCL iteration and that the "time step" of a task is completed when the control flow reaches a "Yield" statement (or the end of a loop with autoyield enabled).
    When I'm running a sequence where a timestep takes longer than the PCL period, the VeriStand engine will abort and undeploy the system definition. In my case the PCL rate is 2KHz so isn't the timeout implicitly given as 500us?
    I thought that maybe I can use the timeout parameter to set an additional timeconstraint from "greater 0 to less than PCL period". So for example if I set it to 0,1ms, the realtime sequence would have to hit a Yield statement within 100us. But this doesn't seem to be the case either because the realtime sequence is not aborted and it still stops the VeriStand engine.
    Thanks
    Krid

    Hi Jarrod,
    thanks for your answer but your second use case is exactly what I tried to do. The VeriStand engine is still aborted even when I run the sequence with timeout set to 0,01:
    Error -307743 occurred at NI VeriStand Engine.lvlib:VeriStand Engine Wrapper (RT).vi >> NI VeriStand Engine.lvlib:VeriStand Engine.vi >> NI VeriStand Engine.lvlib:VeriStand Engine State Machine.vi >> HP Loop.lvlib:HP Loop Main.vi
    I just tested it again and the first time I started the stimulus profile, the realtime sequence actually was aborted and the VeriStand engine continued to run. Then I started the stimulus profile a second time (without changing anything) and this time the profile was not aborted and hence  the VeriStand engine was stopped. It's also not possible to stop the profile in stimulus profile editor. It just hangs and I have to kill it.
    After this happened it's also not possible to run any other realtime sequences (they will simply not start but no error message is returned).  One has to completely close down VeriStand (just re-deploying doesn't work) and restart it before it works again.
    Why isn't the timeout parameter working as it's supposed to?
    Regards
    Krid

  • How can I adjust the Timeout setting?

    I'm running some OBIEE reports in Firefox that by nature do take a long time to run. One of my local Tech Support folks suggested increasing the Firefox Timeout setting (he showed me how to do this once, but I didn't write it down). Can you provide written instructions (or annotated screen pictures), please?

    Alright. There are two ways to do this. You can extend your timeout, or you can totally disable timeout. Depending on the way you use firefox, either may be helpful. If you want to extend your timeout, type about:config in your search bar on the top. From there it will take you to a list of preferences. There is a search bar. Type "Timeout" into it. The top two are disable timeout and the "count timeout". If you want to disable timeout, simply double click the "enabletimeout" on the top. This will change the value to false. If you would like to change the value of how long it takes to timeout, double click the "CountTimeout" and enter in your new value. If this doesn't make sense, see the screenshots.
    Have a great day!!
    -Jon

Maybe you are looking for