TimeOut when calling RemoteWorklistServiceClient.getWorklistTasks

Hi
I have now approx. 1500 open usertasks
and my worklist application for evaluating tasks began
to timeout on call RemoteWorklistServiceClient.getWorklistTasks
Here is code sniplet ( taken from examples and working )
// 1. get a handle to the remove worklist service client
RemoteWorklistServiceClient client = new RemoteWorklistServiceClient();
client.init();
// 2. set approver's user and password
String user = "bpeladmin";
String password = "welcome";
System.out.println("worklistapp: connecting as " + user);
// 3. get worklist context for user
IWorklistContext ctx = client.authenticateUser(user, password);
System.out.println("worklistapp: got Worklist Context");
// 4. set filters for retrieving My tasks with Assigned status
Map filterMap = new HashMap();
filterMap.put(IWorklistService.FILTER_TYPE_TASK_FILTER,
IWorklistService.TASK_FILTER_MY);
filterMap.put(IWorklistService.FILTER_TYPE_STATUS_FILTER,
IWorklistService.STATUS_FILTER_ASSIGNED);
List tasks = client.getWorklistTasks(ctx,
filterMap,
IWorklistService.SORT_FIELD_TASK_TITLE,
IWorklistService.SORT_ORDER_ASCENDING);
Could you please advice me how to increase timeout
or possibly write better code for comleting tasks?
Thanks
Karel

Hi
i answer myself
run following query
select * from pc_task where state='ASSIGNED' and owner='bpeladmin' and title like 'xy%';
grab taskid and call client.customTaskOperation(context, taskid, action)
Karel

Similar Messages

  • Timeout when calling long running Oracle Apps Adapter API calls

    When making a Oracle Apps Based adapter from ESB, Transactions are getting timedout for running calls (~ > 5 mins)
    1) Created a Oracle Apps Adapter to execute a API call that returns, in our case, customer data.
    2) Created a BPEL Which invokes this API based Adapter via. a partner link.
    3) Following errors for calls which take ~ >5, transaction is timeout, when invoked from BPEL/ESB/SOAP UI Client.
    From domain.log
    ==========
    <2009-04-21 18:54:25,718> <DEBUG> <yeruvp.collaxa.cube.ws> <WSIFInvocationHandler::invoke> invoke failed
    org.collaxa.thirdparty.apache.wsif.WSIFException: exception during SOAP invoke: Timed out; nested exception is:
         javax.xml.rpc.soap.SOAPFaultException: Timed out
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.populateFaultMessage(WSIFOperation_JaxRpc.java:3086)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.invokeOperation(WSIFOperation_JaxRpc.java:1728)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.invokeRequestResponseOperation(WSIFOperation_JaxRpc.java:1473)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.executeRequestResponseOperation(WSIFOperation_JaxRpc.java:1196)
         at com.collaxa.cube.ws.WSIFInvocationHandler.invoke(WSIFInvocationHandler.java:476)
         at com.collaxa.cube.ws.WSInvocationManager.invoke2(WSInvocationManager.java:436)
         at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:251)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__invoke(BPELInvokeWMP.java:790)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:395)
         at com.collaxa.cube.engine.ext.wmp.BPELActivityWMP.perform(BPELActivityWMP.java:195)
         at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:3715)
         at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1655)
         at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:75)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:220)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:317)
         at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:5710)
         at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:1085)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.createAndInvoke(CubeEngineBean.java:132)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.syncCreateAndInvoke(CubeEngineBean.java:161)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor$1.run(JAASInterceptor.java:31)
         at com.evermind.server.ThreadState.runAs(ThreadState.java:646)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor.invoke(JAASInterceptor.java:34)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.TxRequiresNewInterceptor.invoke(TxRequiresNewInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeEngineBean_LocalProxy_4bin6i8.syncCreateAndInvoke(Unknown Source)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequestAnyType(DeliveryHandler.java:515)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequest(DeliveryHandler.java:457)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.request(DeliveryHandler.java:131)
         at com.collaxa.cube.ejb.impl.DeliveryBean.request(DeliveryBean.java:95)
         at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor$1.run(JAASInterceptor.java:31)
         at com.evermind.server.ThreadState.runAs(ThreadState.java:646)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor.invoke(JAASInterceptor.java:34)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:50)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at DeliveryBean_RemoteProxy_4bin6i8.request(Unknown Source)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processNormalOperation(SOAPRequestProvider.java:451)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processBPELMessage(SOAPRequestProvider.java:274)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processMessage(SOAPRequestProvider.java:120)
         at oracle.j2ee.ws.server.provider.ProviderProcessor.doEndpointProcessing(ProviderProcessor.java:956)
         at oracle.j2ee.ws.server.WebServiceProcessor.invokeEndpointImplementation(WebServiceProcessor.java:349)
         at oracle.j2ee.ws.server.provider.ProviderProcessor.doRequestProcessing(ProviderProcessor.java:466)
         at oracle.j2ee.ws.server.WebServiceProcessor.processRequest(WebServiceProcessor.java:114)
         at oracle.j2ee.ws.server.WebServiceProcessor.doService(WebServiceProcessor.java:96)
         at oracle.j2ee.ws.server.WebServiceServlet.doPost(WebServiceServlet.java:177)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
         at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
         at oracle.security.jazn.oc4j.JAZNFilter$1.run(JAZNFilter.java:396)
         at java.security.AccessController.doPrivileged(Native Method)
         at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
         at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:410)
         at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:623)
         at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370)
         at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:871)
         at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453)
         at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:302)
         at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:190)
         at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    Caused by: javax.xml.rpc.soap.SOAPFaultException: Timed out
         at oracle.j2ee.ws.client.StreamingSender._raiseFault(StreamingSender.java:568)
         at oracle.j2ee.ws.client.StreamingSender._sendImpl(StreamingSender.java:396)
         at oracle.j2ee.ws.client.StreamingSender._send(StreamingSender.java:112)
         at oracle.j2ee.ws.client.dii.CallInvokerImpl.directInvoke(CallInvokerImpl.java:726)
         at oracle.j2ee.ws.client.dii.BasicCall.directInvoke(BasicCall.java:743)
         at oracle.j2ee.ws.client.dii.BasicCall.invoke(BasicCall.java:649)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.invokeOperation(WSIFOperation_JaxRpc.java:1714)
         ... 83 more
    <2009-04-21 18:54:25,721> <ERROR> <yeruvp.collaxa.cube.ws> <WSIFInvocationHandler::invoke> Fault happened: exception during SOAP invoke: Timed out; nested exception is:
         javax.xml.rpc.soap.SOAPFaultException: Timed out
    <2009-04-21 18:54:25,752> <DEBUG> <yeruvp.collaxa.cube.engine> AJPRequestHandler-RMICallHandler-61, a4 <invoke> partner OrgCustAdapter_pl, wikey:7990001-BpInv0-BpSeq0.3-3, bpel code line:84, Connection info:oracle_jdbc_driver_T4CConnection_Proxy@17f3851, connection hashCode:25114705, autocommit:false, Transaction info:[Transaction : orabpel : Xid( Global Id 1b.16.00.7d.00.00.00.00.2f.d3.6d.ca.20.01.00.00.17.41.03.00.00.00.00.00, Format Id 1330790740)], jtaTxState:1, CubeInstance:7990001, Process name:testCustomer_BPEL
    Now looking to troubleshoot this Timed out issue.
    i, Does this need to increase any configuration file timeout parameter on EBS Adapter or other component ?
    Any suggessions to fix/towards resolution is appricated.
    Thanks,
    sgaraga

    After increasing sync-time-out and global transaction time out to 1800. Issue is still reported.
    We are not using the jdbc pool.
    Still not sure what we are missing here and running into this:
    WSIFInvocationHandler::invoke> invoke failed
    org.collaxa.thirdparty.apache.wsif.WSIFException: exception during SOAP invoke: Timed out; nested
    exception is:
    javax.xml.rpc.soap.SOAPFaultException: Timed out
    In addition:
    ========
    Tested calling this PL/SQL API (exactly the same API CALLED in BPEL) in TOAD and this ran for 20 mts in DB.
    With the changes(sync-time-out,global transaction time,hpptd.conf, and transaction-manager.xml ) in SOA configuration then we are getting the exception ..
    So, we need help with SOA configuration to get the BPEL service working when the API called within BPEL service is taking approximately 20 mts.
    Edited by: sgaraga on Apr 22, 2009 4:29 PM

  • Timeout when calling Oracle Apps Adapter API calls.

    1) Create a Oracle Apps Adapter to execute a API call that returns, in our case, customer data.
    2) Create a BPEL Which invokes this API based Adapter via. a partner link.
    Observations:
    A) Posts the following errors for calls which take ~ >5, transaction is timeout, when invoked from BPEL/ESB/SOAP UI Client.
    <2009-04-21 18:54:25,718> <DEBUG> <yeruvp.collaxa.cube.ws> <WSIFInvocationHandler::invoke> invoke failed
    org.collaxa.thirdparty.apache.wsif.WSIFException: exception during SOAP invoke: Timed out; nested exception is:
         javax.xml.rpc.soap.SOAPFaultException: Timed out
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.populateFaultMessage(WSIFOperation_JaxRpc.java:3086)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.invokeOperation(WSIFOperation_JaxRpc.java:1728)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.invokeRequestResponseOperation(WSIFOperation_JaxRpc.java:1473)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.executeRequestResponseOperation(WSIFOperation_JaxRpc.java:1196)
         at com.collaxa.cube.ws.WSIFInvocationHandler.invoke(WSIFInvocationHandler.java:476)
         at com.collaxa.cube.ws.WSInvocationManager.invoke2(WSInvocationManager.java:436)
         at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:251)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__invoke(BPELInvokeWMP.java:790)
         at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:395)
         at com.collaxa.cube.engine.ext.wmp.BPELActivityWMP.perform(BPELActivityWMP.java:195)
         at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:3715)
         at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1655)
         at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:75)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:220)
         at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:317)
         at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:5710)
         at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:1085)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.createAndInvoke(CubeEngineBean.java:132)
         at com.collaxa.cube.engine.ejb.impl.CubeEngineBean.syncCreateAndInvoke(CubeEngineBean.java:161)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor$1.run(JAASInterceptor.java:31)
         at com.evermind.server.ThreadState.runAs(ThreadState.java:646)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor.invoke(JAASInterceptor.java:34)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.TxRequiresNewInterceptor.invoke(TxRequiresNewInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at CubeEngineBean_LocalProxy_4bin6i8.syncCreateAndInvoke(Unknown Source)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequestAnyType(DeliveryHandler.java:515)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.initialRequest(DeliveryHandler.java:457)
         at com.collaxa.cube.engine.delivery.DeliveryHandler.request(DeliveryHandler.java:131)
         at com.collaxa.cube.ejb.impl.DeliveryBean.request(DeliveryBean.java:95)
         at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor$1.run(JAASInterceptor.java:31)
         at com.evermind.server.ThreadState.runAs(ThreadState.java:646)
         at com.evermind.server.ejb.interceptor.system.JAASInterceptor.invoke(JAASInterceptor.java:34)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.TxRequiredInterceptor.invoke(TxRequiredInterceptor.java:50)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
         at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
         at com.evermind.server.ejb.StatelessSessionEJBObject.OC4J_invokeMethod(StatelessSessionEJBObject.java:87)
         at DeliveryBean_RemoteProxy_4bin6i8.request(Unknown Source)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processNormalOperation(SOAPRequestProvider.java:451)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processBPELMessage(SOAPRequestProvider.java:274)
         at com.collaxa.cube.ws.soap.oc4j.SOAPRequestProvider.processMessage(SOAPRequestProvider.java:120)
         at oracle.j2ee.ws.server.provider.ProviderProcessor.doEndpointProcessing(ProviderProcessor.java:956)
         at oracle.j2ee.ws.server.WebServiceProcessor.invokeEndpointImplementation(WebServiceProcessor.java:349)
         at oracle.j2ee.ws.server.provider.ProviderProcessor.doRequestProcessing(ProviderProcessor.java:466)
         at oracle.j2ee.ws.server.WebServiceProcessor.processRequest(WebServiceProcessor.java:114)
         at oracle.j2ee.ws.server.WebServiceProcessor.doService(WebServiceProcessor.java:96)
         at oracle.j2ee.ws.server.WebServiceServlet.doPost(WebServiceServlet.java:177)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
         at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
         at oracle.security.jazn.oc4j.JAZNFilter$1.run(JAZNFilter.java:396)
         at java.security.AccessController.doPrivileged(Native Method)
         at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
         at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:410)
         at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:623)
         at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370)
         at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:871)
         at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453)
         at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:302)
         at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:190)
         at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    Caused by: javax.xml.rpc.soap.SOAPFaultException: Timed out
         at oracle.j2ee.ws.client.StreamingSender._raiseFault(StreamingSender.java:568)
         at oracle.j2ee.ws.client.StreamingSender._sendImpl(StreamingSender.java:396)
         at oracle.j2ee.ws.client.StreamingSender._send(StreamingSender.java:112)
         at oracle.j2ee.ws.client.dii.CallInvokerImpl.directInvoke(CallInvokerImpl.java:726)
         at oracle.j2ee.ws.client.dii.BasicCall.directInvoke(BasicCall.java:743)
         at oracle.j2ee.ws.client.dii.BasicCall.invoke(BasicCall.java:649)
         at com.collaxa.cube.ws.wsif.providers.oc4j.jaxrpc.WSIFOperation_JaxRpc.invokeOperation(WSIFOperation_JaxRpc.java:1714)
         ... 83 more
    <2009-04-21 18:54:25,721> <ERROR> <yeruvp.collaxa.cube.ws> <WSIFInvocationHandler::invoke> Fault happened: exception during SOAP invoke: Timed out; nested exception is:
         javax.xml.rpc.soap.SOAPFaultException: Timed out
    <2009-04-21 18:54:25,752> <DEBUG> <yeruvp.collaxa.cube.engine> AJPRequestHandler-RMICallHandler-61, a4 <invoke> partner OrgCustAdapter_pl, wikey:7990001-BpInv0-BpSeq0.3-3, bpel code line:84, Connection info:oracle_jdbc_driver_T4CConnection_Proxy@17f3851, connection hashCode:25114705, autocommit:false, Transaction info:[Transaction : orabpel : Xid( Global Id 1b.16.00.7d.00.00.00.00.2f.d3.6d.ca.20.01.00.00.17.41.03.00.00.00.00.00, Format Id 1330790740)], jtaTxState:1, CubeInstance:7990001, Process name:testCustomer_BPEL
    Now i am looking to troubleshoot this Timed out issue.
    i, Does this need to increase any configuration file timeout parameter on EBS Adapter or other component ?
    Any suggestions to fix/towards resolution is appreciated.
    Thanks,
    sgaraga

    After increasing sync-time-out and global transaction time out to 1800. Issue is still reported.
    We are not using the jdbc pool.
    Still not sure what we are missing here and running into this:
    WSIFInvocationHandler::invoke> invoke failed
    org.collaxa.thirdparty.apache.wsif.WSIFException: exception during SOAP invoke: Timed out; nested
    exception is:
    javax.xml.rpc.soap.SOAPFaultException: Timed out
    In addition:
    ========
    Tested calling this PL/SQL API (exactly the same API CALLED in BPEL) in TOAD and this ran for 20 mts in DB.
    With the changes(sync-time-out,global transaction time,hpptd.conf, and transaction-manager.xml ) in SOA configuration then we are getting the exception ..
    So, we need help with SOA configuration to get the BPEL service working when the API called within BPEL service is taking approximately 20 mts.
    Edited by: sgaraga on Apr 22, 2009 4:29 PM

  • Labview gpib timeout when calling cvi dll

    Equipment used :
    VXI Rack with Slot 0 controller
    Labview V5.0.1
    Lab Windows V5.0.1
    GPIB controlled Power10 I63 PSU
    We run an intermediate Labview driver which communicates with a low level CVI driver (dll) to control a PSU.  We recently tried to run the Labview driver on a Slot 0 controller and we get timeout errors when waiting for a response after commanding the PSU to switch off ( "CST OFF" is sent , and the driver waits on "ST OFF" being returned - it never does and times out).  Ni Spy is on when it fails.  In the same driver, a call to return the Instrument ID is carried out happily, with the ID being returned with no errors.
    I can run the low level CVI driver with an interactive script and it works fine with no errors.
    I can run the Labview driver with NI Spy switched off and it works ok too,  Our customer cannot get it to work even with Ni Spy switched off.  They have the same setup as us.
    Any ideas?

    The solution I had previously documented only partly worked.  It cleared the timeout error, but I am still experiencing various errors in testing the PSU with Labview (still no problems with running the functions with Labwindows directly).  Also, if NISpy is running I see no errors, which still leads me to believe its a timing problem.  I saw another thread on here from someone with similar problems and I tried all the recomendations in that, but it still did not fix it.  The last recomendation was to re-write the GPIB driver to slow down the message transfer to the instrument! 
    A link to the thread with similar problems to mine.....
    http://forums.ni.com/ni/board/message?board.id=140&message.id=20031
    Message Edited by edinsofty1 on 09-09-2008 07:21 AM
    Message Edited by edinsofty1 on 09-09-2008 07:21 AM

  • Timeouts when calling functions

    We have an application that makes use of functions within SAP.  We call these functions with v2 of the .NET connector but occasionally these take quite long and either the user sits twiddling their thumbs for ages or a SAP dump is produced and the application crashes.  I have two questions:
    1) Can we stop a function call after we have started it? (Note: The function module is executing ABAP created from the application)
    2) What is the best way to deal with timeouts?  (Is there anyway to stop the dump from being produced?)
    TIA,
    -Charles

    The connector allows you to do asynchronous calls to the ""proxied"" RFC functions.
    This way you can define your own "timeout".
    Regards,
    Ofer

  • Return 504 Gateway TimeOut when access exchange service by domain/user and password

    hi,
    here is the scenario: a user of our app is in ntdev domain, and his exchange server located at apj.cloudmail.microsoft.com. our backend api is deployed at the Azure servers at US West.
    our api get 504 Gateway Timeout when calling the
    FindFolders API of exchangeService. does anyone know how to fix this issue? the following is the core code:
    var
    service = newExchangeService(ExchangeVersion.Exchange2010);
    service.Credentials =
    newNetworkCredential(username,
    password, domain);
    service.AutodiscoverUrl(emailAddress, RedirectionUrlValidationCallback);
    service.FindFolders(
    WellKnownFolderName.Root,
    newFolderView(1));

    That doesn't sound like its an EWS issue more an issue with the Network path your trying to traverse to the Exchange Server. My suggestion is that you test EWS using the EWSeditor
    https://ewseditor.codeplex.com/ (eg it sounds like you may have proxy server that expecting authentication etc.).
    Cheers
    Glen

  • SetQueryTimeout when calling stored procedures

    I cannot seem to get a query to timeout when calling a stored procedure in Oracle 8i. I have set the query timeout to 1 (sec.) and the query takes a few minutes to return. I get no exception and the query returns normally. When I use a prepared statement the query times out as expected and I get an exception. Should this work?

    Hi,
    The issue: I want a timeout on database locks, without doing
    a select for update wait x/ or nowait for every row concerned.
    Once the thread called java.net.SocketInputStream.socketread0() (unfortunatelly
    without a timeout), I currently only see 2 ways to get my thread out of there:
    - The lock is resolved (by the blocking instance) resp. the db server
    - By calling System.exit() (which I do not wish to do)
    So I want the Oracle Driver to call socketRead with a timeout, or if
    i can't do so. I'd like to set the timeout to the Socket myself.
    Or if I can't do so either, I plan to give a new SocketImplFactory
    to my client VM, which will implement a Socket with a fixed timeout
    on reads.
    Hint's (what I found out so far):
    - Calling interrupt on the invoking Thread wan't help
    - Calling statement.setQueryTimeout() wan't help, because the SqlException
    will be thrown at the time the statement leaves the socketRead(), which is
    when to lock is resolved, which is too late
    - The timeout used is defined by the used SocketImpl, which
    is by default the java.net.PlainSocketImpl, which is by default 0, which means
    'wait forever'
    - I did not found a way to set a timeout on the db server side, to resolve
    this problem
    Details:
    I am using Oracles JDBC Thin Driver 9i 9.2.0.3
    So far I did not specify any additional properties to the ConnectionFactory
    than user/pwd

  • How can I interrupt the blocking call when call timeout?

    Hi,Guys
    I wrote an application server(daemon process) to talk with oracle server
    continuous which used oracle9 OCCI lib, each 5 min it executes the procedure
    on the DB server.
    Now I have come cross a problem:
    If the network is blocked, app server will blocked at occi call and would
    never pass, and no exception was catched :-(
    for e.g.
    1. Oracle server reboot without shutdown oracle process
    2. udp broadcast message storm blocked the connection between app server and
    oracle DB.
    I consider maybe it's because OCCI using the blocking mode of connection
    that caused this problem.
    How can I interrupt the blocking call when call timeout?

    Manage the timeout using a separate thread. When the timeout happens, issue a break on the OCCI connection. There is no direct way as of now. You need to do this to break a OCCI connection.
    retrieve the OCI handle from the OCCI handle (e.g. using Connection::getOCIServer or Connection::getOCIServiceContext methods) and issue a OCIBreak on it. Do not forget to allocate a error handle which should be passed to OCIBreak call.

  • Timeout not working when calling stored procedure

    Hi,
    We have a Win32 application connected to ORACLE using ODBC API.
    A stored procedure (doing INSERT into 3 tables) is called via
    SQLPrepare and SQLExecute("{CALL SP(IN param...) ...}"), but
    Oracle never time out the statement.
    There are 2 types of modified timeouts:
    SQL_ATTR_QUERY_TIMEOUT = 20
    SQL_ATTR_CONNECTION_TIMEOUT = 60
    Even if I set LockTimeOut parameter in ORAODBC.ini file, it
    still doesn't work.
    I tried with SQLExecDirect("INSERT...") and it works fine.
    - Does time out works with oracle Stored Procedure ?
    - If not, how can I avoid application hangs when calling
    SQLExecute ?
    - I use "lock table MY_TABLE in exclusive mode" to simulate
    query timing out. Is the better way to do this ?
    Please, any help would be GREATLY appreciated :-)
    Thanks.
    -Dario Efine
    [email protected]
    Infos:
    - Application running on WinNT4 SP6a,
    - Oracle ODBC for Oracle 8.01.76.00,
    - Stored procedure has 10 IN parameters, it also uses 2 inner
    small functions.

    HiTopp wrote:
    I get a "Login Failed for user _____" error if I attempt to use incorrect credentials.
    That message is very likely coming from the database. To be sure, turn debugging on in the ColdFusion Administrator. Also check out the logs. We have to narrow this down, otherwise we could end up running circles.
    If the attribute pairs [username="valid_name", password="valid_password"] and [username="", password=""] work, but [username="valid_name", password="invalid_password"] fails, then the cause of the problem is most probably your code, and how it connects to the database(s). Could you show us all (or at least more) of the code?
    My first suggestion to you was to omit the line variables.storedProcService.clear();. Invoking clear() only makes sense when it occurs after addProcResults() or addParam(). Did you omit the line? What was the effect, with and without credentials?
    Could you please describe your infrastructure a bit more. From what I understand, there are at least 2 servers, S1 and S2. Let's say, ColdFusion is installed on S1. I am assuming from what has gone before that SQL Server, which runs the stored procedure, is on the second server S2.
    Go to the 'Client Variables' page in the ColdFusion Administrator. Verify that ColdFusion is indeed configured to use a database for client storage. What is the name of the datasource used as client store? Now, proceed to the datasource page and check out the settings for the client datasource. To which machine/database server does this datasource point?
    Jot down the server settings and credentials of the other datasources configured in the Administrator. To which machine/database server do these datasources point?

  • Re: [iPlanet-JATO] Re: session timeout when not submitting to a handler

    Mark--
    I know what's happening here, but am curious about your approach. You said
    in an earlier email that you were generating links directly to JSPs, but
    from what you are describing, you are generating JATO-style links to access
    JATO pages. Nothing wrong with that, but there is a signficant difference.
    Actually, it just occurred to me, I'm wondering what your URLs look like.
    The way the request dispatching works in JATO is it ignores anything after
    an initial "." in the final part of the URL path. For example, a request
    for "/myapp/module1/MyPage.jsp" doesn't actually try to hit the JSP, instead
    it tries to hit the JATO page "/myapp/module1/MyPage".
    The end result is that you may think you are accessing a JSP directly, but
    are instead accessing a JATO page. The reason the request dispatching works
    this way is because it is illegal to access JATO JSPs directly, and there is
    actually a (disabled) JATO feature that piggybacks on the use of the
    dot-delimited URL.
    So, now I need to understand your intent. I wasn't really sure why you were
    generating direct JSP/page links to begin with. This works against the Type
    II architecture JATO uses, in which all JATO requests go back to the
    controller servlet.
    If you are trying to design something like a menu page, you may have thought
    that it was burdensome to create a number of HREF children, plus implement
    event handlers for each of them. This definitely would be burdensome beyond
    just a handful of links, but this is why JATO provides other mechanisms for
    doing what I'll call here "polymorphic HREFs".
    Assuming this menu page scenario, the easiest thing to do is to simply use
    one HREF child on the page, and add a value to it each time it is rendered
    that distinguishes it from the other instances on the page. In your event
    handler for the HREF, you simply check this value and use it to decide which
    page to forward to. You can add a value to an HREF or Button by using the
    "addExtraValue()" method. Or, if you are using JATO 1.2, you can add extra
    query string NVPs right in the JSP document using the "queryParams"
    attribute of the <jato:href> tag. Thus, your one HREFchild and event
    handler become "polymorphic" because what they do depends on the context in
    which they are invoked.
    Now, I still don't have confirmation that this is what you were trying to
    do, so until I do, let me explain the exception you're seeing. JATO assumes
    that when a request comes in for a page that includes the pageAttributes
    NVP, it is a request coming from a previously generated JATO page. Because
    of the way JATO works, this means that the request dispatching code should
    send the request back to the originally rendered page. For example, if Page
    A renders an HREF, which the user then activates, JATO sends the request
    back to Page A for handling. All of the HREFs and forms generated during
    rendering of Page A actually refer back to Page A, regardless of where those
    links or buttons actually pass the request in their event handlers/Command
    objects.
    So, what's happening when you include the pageAttributes in your HREFs is
    that JATO is assuming that a request is being sent to the target page, with
    the assumption that the target page has a mechanism in place to handle the
    request. This assumption relies on the specification of the "originator" of
    the request being specified in the request. For links/HREFs, the name and
    value of the HREF is sent along with the request. For forms, the name and
    value of the button that was pressed are sent in the request. JATO uses the
    presence of these name/value pairs to decide which event handler, or which
    Command object, to invoke to handle the request.
    The exception you are receiving is saying that there was no object on the
    target page that indicated it could handle the request. This is to be
    expected, since you have not specified a query parameter that indicates
    which CommandField child is responsible the request. However, this is where
    I see the disconnect, because that is not what I believe you were trying to
    do (as explained above).
    So now, given all the information above, can you tell me what you're trying
    to accomplish, and whether or not the info I've given you has helped you to
    design a mechanism more in line with a JATO approach? If not, given that I
    understand what you're trying to do, I can offer a more concrete solution.
    Todd
    ----- Original Message -----
    From: <Mark_Dubinsky@p...>
    Sent: Monday, November 05, 2001 2:54 PM
    Subject: [iPlanet-JATO] Re: session timeout when not submitting to a handler
    This is the exception we get:
    (And BTW, leaving a blank value for the pageAttributes doesn't help)
    [05/Nov/2001 17:49:18:4] error: <portalServlet.processRequest>
    javax.servlet.ServletException: The request was not be handled by the
    specified handler
    at java.lang.Throwable.fillInStackTrace(Native Method)
    at java.lang.Throwable.fillInStackTrace(Compiled Code)
    at java.lang.Throwable.<init>(Compiled Code)
    at java.lang.Exception.<init>(Compiled Code)
    at
    javax.servlet.ServletException.<init>(ServletException.java:107)
    at
    com.putnaminvestments.common.jato.ApplicationServletBase.dispatchRequ
    est(Compiled Code)
    at
    com.putnaminvestments.common.jato.ApplicationServletBase.processReque
    st(Compiled Code)
    at
    com.putnaminvestments.bp.portal.portalServlet.processRequest(Compiled
    Code)
    at
    com.putnaminvestments.common.jato.ApplicationServletBase.doPost(Compi
    led Code)
    at
    com.putnaminvestments.common.jato.ApplicationServletBase.doGet(Compil
    ed Code)
    at javax.servlet.http.HttpServlet.service(Compiled Code)
    at com.putnaminvestments.bp.bpServletBase.service(Compiled
    Code)
    at javax.servlet.http.HttpServlet.service(Compiled Code)
    at
    com.netscape.server.servlet.servletrunner.ServletInfo.service(Compile
    d Code)
    at
    com.netscape.server.servlet.servletrunner.ServletRunner.execute(Compi
    led Code)
    at com.kivasoft.applogic.AppLogic.execute(Compiled Code)
    at com.kivasoft.applogic.AppLogic.execute(Compiled Code)
    at com.kivasoft.thread.ThreadBasic.run(Native Method)
    at com.kivasoft.thread.ThreadBasic.run(Native Method)
    at com.kivasoft.thread.ThreadBasic.run(Native Method)
    at com.kivasoft.thread.ThreadBasic.run(Native Method)
    at com.kivasoft.thread.ThreadBasic.run(Compiled Code)
    at java.lang.Thread.run(Compiled Code)
    --- In iPlanet-JATO@y..., "Todd Fast" <Todd.Fast@S...> wrote:
    Mark--
    Initially we tried to add the pageAttributes NVP as well, but that
    was
    causing an exception, so we stopped doing that.That's odd--what was the exception?
    Our problem now is that when the SessionTimes out it does not go
    to
    onSessionTimeout method as in processRequestMethod of the
    ApplicationServletBase it looks for pageAttributes. If it is notnull
    then only onSessionTimeOut method is called.This is sadly the only technique for determining if a session hastimed out
    and a new one been created, versus the initial creation of thesession.
    Is there any work around for this? Maybe you can suggest how topass
    the pageAttributes without causing the initial exception?Definitely--let me know what the exception was and I'll be able tosuggest
    something. However, it shouldn't really be any harder thanappending a
    "jato.pageAttributes=" empty NVP on the HREF.
    Todd
    Todd Fast
    Senior Engineer
    Sun/Netscape Alliance
    todd.fast@s...
    For more information about JATO, please visit:
    http://developer.iplanet.com/tech/appserver/framework/index.jsp

    OK, here's what I'm trying to do: We have, like you said, a menu
    page. The pages that it goes to and the number of links are all
    variable and read from the database. In NetD we were able to create
    URLs in the form
    pgXYZ?SPIDERSESSION=abcd
    so this is what I'm trying to replicate here. So the URL that works
    is
    pgContactUs?GXHC_GX_jst=fc7b7e61662d6164&GXHC_gx_session_id_=cc9c6dfa5
    601afa7
    which I interpreted to be the equivalent of the old Netd way. Our
    javascript also loads other frames of the page in the same manner.
    And I believe the URL-rewritten frame sources of a frameset look like
    this too.
    This all worked except for the timeout problem. In theory we could
    rewrite all URLs to go to a handler, but that would be...
    inconvenient.

  • ABAP process hangs when calling a jCO Server J2EE-available RFC

    Hi there
    Here's the scenario:
    We have deployed a jCO server under the SAP WAS. This jCO server implements two functions. They are both called from ABAP process through RFC. We are using the same RFC destination for both
    First function is defined with import/export parameters and the second one only operates with a TABLE parameter.
    Incidentally, these functions are captured by the jCO server, which calls an IBM MQ server
    First function works fine. Second function hangs and there is not even a timeout so the ABAP process (run on foreground) can stay forever.
    The interesting part is that the same application works really fine when called from a Tomcat using a standalon instance of the jCO.
    Additional info:
    We have noticed that some time after the second function gets called, there are five dumps on the system (the same amount of servers we make available). These are CALL_FUNCTION_SIGNON_REJECTED.
    The fun part of the dumps is that the user making the RFC call is a different user that the one we use for the jCO connection, and the client number is '000', instead of the '728' we are using for the connection. Somehow they seem related but we do not know how yet:
    Short text
        You are not authorized to logon to the target system (error code 1).
    What happened?
        Error in the ABAP Application Program
        The current ABAP program "SAPMSSY1" had to be terminated because it has
        come across a statement that unfortunately cannot be executed.
    Error analysis
        RFC (Remote Function Call) sent with invalid
        user ID "%_LOG01% " or client 000.
        User "ARINSO " under client 001 from system "SMD " has tried to carry out an
         RFC
        call under the user ID "%_LOG01% " and client 000 (Note: For releases < 4.0,
         the
         information on caller and caller system do not exist.).
    Call Program........."SAPLSMSY_ACTUALIZE_DATA"
    Function Module..... "SCSM_SYSTEM_LIST"
    Call Destination.... "SM_ET7CLNT000_READ"
    Source Server....... "sapwasmd_SMD_10"
    Source IP Address... "172.17.82.80"
    Termination occurred in the ABAP program "SAPMSSY1" - in
         "REMOTE_FUNCTION_CALL".
        The main program was "SAPMSSY1 ".
        In the source code you have the termination point in line 67
        of the (Include) program "SAPMSSY1".
    Any tip or suggestion on where to look at is more than welcome
    Thanks in advance,
    Miguel

    And this is the content of the defaultTrace.0.trc log from the WAS
    1.#005056AB04C500440000000200002B0000046B495CA1AF67#1243862737727#com.sap.caf.um.relgrou
    ps.imp.principals.RelGroupFactory##com.sap.caf.um.relgroups.imp.principals.RelGroupFactor
    y.RelGroupFactory()#######SAPEngine_System_Thread[impl:5]_13##0#0#Info#1#/System/Server#P
    lain###sap.com caf/um/relgroups/imp MAIN_NW701P03_C 2846629#
    #1.#005056AB04C500240000000100002B0000046B495CCDAAFB#1243862740608#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/System Threads Pool/WaitingTasksCount>: com.sap.engine.library.monitor.
    mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for node'/Kerne
    l/System Threads Pool/WaitingTasksCount' (MANAGERS.SThreadPool.WaitingInRequestQueueCount
    , max. 40 characters)#
    #1.#005056AB04C500240000000200002B0000046B495CCDB4CC#1243862740612#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/System Threads Pool/WaitingTasksQueueOverflow>: com.sap.engine.library.
    monitor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for nod
    e'/Kernel/System Threads Pool/WaitingTasksQueueOverflow' (MANAGERS.SThreadPool.Waiting4Fr
    eeReqQueueSlotCount, max. 40 characters)#
    #1.#005056AB04C500240000000300002B0000046B495CCDCDA1#1243862740618#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/Application Threads Pool/WaitingTasksCount>: com.sap.engine.library.mon
    itor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for node'/
    Kernel/Application Threads Pool/WaitingTasksCount' (MANAGERS.AThreadPool.WaitingInRequest
    QueueCount, max. 40 characters)#
    #1.#005056AB04C500240000000400002B0000046B495CCDD69B#1243862740620#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/Application Threads Pool/WaitingTasksQueueOverflow>: com.sap.engine.lib
    rary.monitor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group fo
    r node'/Kernel/Application Threads Pool/WaitingTasksQueueOverflow' (MANAGERS.AThreadPool.
    Waiting4FreeReqQueueSlotCount, max. 40 characters)#
    #1.#005056AB04C500600000001600002B0000046B4960688301#1243862801089#com.sap.slm.exec.messa
    ge.SLMApplication#sap.com/tcslmslmapp#com.sap.slm.exec.message.SLMApplication#Guest#0##
    n/a##c59827604eaf11de9fb3005056ab04c5#SAPEngine_Application_Thread[impl:3]_0##0#0#Error##
    Java###null##
    #1.#005056AB04C500730000000000002B0000046B4CF0593ABD#1243878100908#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain###com.sap.mw.jco.JCO$AbapException: (126) 1: Array index out of rang
    e: 48#
    #1.#005056AB04C500730000000100002B0000046B4CF0594028#1243878100909#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.efh.jco.valtran.sap.ValtranRequestHandler.serverExceptionO
    ccurred(ValtranRequestHandler.java:164)#
    #1.#005056AB04C500730000000200002B0000046B4CF059406B#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO.fireServerExceptionOccurred(JCO.java:880)#
    #1.#005056AB04C500730000000300002B0000046B4CF05940A3#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.listen(JCO.java:8187)#
    #1.#005056AB04C500730000000400002B0000046B4CF05940DB#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.work(JCO.java:8303)#
    #1.#005056AB04C500730000000500002B0000046B4CF0594111#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.loop(JCO.java:8250)#
    #1.#005056AB04C500730000000600002B0000046B4CF0594143#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.run(JCO.java:8166)#
    #1.#005056AB04C500730000000700002B0000046B4CF05941F0#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at java.lang.Thread.run(Thread.java:770)#

  • Setting some QoS params when calling stored procedures

    Hi All,
    Can I set some QoS params when calling a stored procedure like Timeout, Connection Timeout, Retry Count, etc?
    Thanks,
    Daniel

    Since anything between your client and your data can fail(including connectivity to the ALDSP server), we recommend that you exercise retries and timeouts from the client. If you attempt to implement retries and timeouts within the XQuery - you open up several cans of worms.(mentioned later) There is a Query Attribute (in RequestConfig) that you can use to specify a timeout on the query. And you can implement retries with a loop (for, while etc).
    If you use timeout/fail-over in your query - a number of things happen. First, if something happens outside your timeout or retry - you'll miss it (i.e. if someone unplugs one of your ALDSP servers, the fail-over in your xquery is not going to help). Second, adding timeout/fail-over function calls into your XQuery blocks query optimizations - if you put a fail-over around access to a CUSTOMER table in a database, the optimizer cannot combine that with an access to the ORDER table in the same database). Third, in ALDSP 2.5, the database connections within a query are cached, so if you have Oracle RAC, and one instance goes down - the fail-over function will fail-over to the same instance (unless you create a duplicate data source for the same RAC, but with a different name).
    ALDSP does not provide means to configure retries (like ALSB does).
    You can explicitly attempt to call a stored procedure mutliple times using the fn-bea:fail-over function.
    You can also retry (in case of timeout) by using the fn-bea:timeout function.
    Note that during a single query execution, if an instance of fail-over actually fails-over - it will not bother to evaluate the primary expression again during that query execution - it will simply evaluate the secondary expression. (The idea being that if a web service is down, then it will still be down a few milliseconds later). You can contact Customer Support if you need different functionality (there is a fail-over-retry function available in a patch).
    If you are calling a replicated web-service, you can implement round-robin in a web-service handler for that web service. Ask if you want an example.

  • Deadlock when calling cache.containsKey()

    Hi,
    Under heavy load, we sometimes experience a timeout when putting data in a distributed cache. In the example below we made a call to the containsKey() method of the "EVENTS" cache at 17:04:59 which never returned. When our execution timed out 1 minute later we received the following stack trace:
    20 Feb 2009 17:05:57,667 [gridgain-#70%null%:grid-job-worker] ERROR server.common.aspect.ExceptionHandlingAspect - Handling Throwable for joinPoint execution(Serializable com.t
    raficon.tmsng.server.common.message.ProcessMessageJob.execute())
    (Wrapped) java.lang.InterruptedException
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:485)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.poll(Grid.CDB:31)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.poll(Grid.CDB:11)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.DistributedCache$BinaryMap.containsKey(DistributedCache.CDB:24)
    at com.tangosol.util.ConverterCollections$ConverterMap.containsKey(ConverterCollections.java:1494)
    at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.DistributedCache$ViewMap.containsKey(DistributedCache.CDB:1)
    at com.tangosol.coherence.component.util.SafeNamedCache.containsKey(SafeNamedCache.CDB:1)
    at com.tangosol.net.cache.CachingMap.containsKey(CachingMap.java:400)
    at com.traficon.tmsng.server.common.cache.impl.coherence.CoherenceMessageCacheFacade.hasDuplicate(CoherenceMessageCacheFacade.java:445)
    at com.traficon.tmsng.server.common.cache.impl.coherence.CoherenceMessageCacheFacade.addEventMessage(CoherenceMessageCacheFacade.java:131)
    at com.traficon.tmsng.server.common.process.impl.MessageProcessorImpl.process(MessageProcessorImpl.java:115)
    at com.traficon.tmsng.server.common.message.ProcessMessageJob.execute(ProcessMessageJob.java:57)
    at org.gridgain.grid.kernal.processors.job.GridJobWorker.body(GridJobWorker.java:406)
    at org.gridgain.grid.util.runnable.GridRunnable$1.run(GridRunnable.java:142)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at org.gridgain.grid.util.runnable.GridRunnable.run(GridRunnable.java:194)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)
    Any idea why this is? The call is not executed within a coherence service thread and I think I made sure none of my custom filters, entryProcessors, valueUpdaters etc make any re-entrant calls.
    Below you can find the coherence-config.xml:
    <cache-config>
    <caching-scheme-mapping>
    <cache-mapping>
    <cache-name>DATA_STORE</cache-name>
    <scheme-name>outputNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>EVENTS</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>REDUNDANT_EXECUTOR</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>NODE_MONITOR</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>MEMORY_MONITOR</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>DATABASE_MONITOR</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>DETECTOR_COMMUNICATOR_MANAGER_LISTENER</cache-name>
    <scheme-name>inputNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>REMOTE_FILTER_MONITOR</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>LOCK_MONITOR</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>EVENT_NUMBER</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>VERIFY_CONFIGURATION</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    <cache-mapping>
    <cache-name>OPEN_UNKNOWN_CONFIGURATION</cache-name>
    <scheme-name>processNear</scheme-name>
    </cache-mapping>
    </caching-scheme-mapping>
    <caching-schemes>
    <near-scheme>
    <scheme-name>inputNear</scheme-name>
    <front-scheme>
    <local-scheme>
              <service-name>InputFrontService</service-name>
         <eviction-policy>LRU</eviction-policy>
         <high-units>10000</high-units>
         <expiry-delay>10m</expiry-delay>
         <flush-delay>5m</flush-delay>
    </local-scheme>
    </front-scheme>
    <back-scheme>
         <distributed-scheme>
         <service-name>InputBackService</service-name>
         <backing-map-scheme>
         <local-scheme>
                        <service-name>InputBackLocalService</service-name>
         </local-scheme>
         </backing-map-scheme>
         <local-storage system-property="tangosol.coherence.inputNode">false</local-storage>
         <autostart system-property="tangosol.coherence.inputNode">false</autostart>
         </distributed-scheme>
    </back-scheme>
    <invalidation-strategy>present</invalidation-strategy>
    <autostart system-property="tangosol.coherence.inputNode">false</autostart>
    </near-scheme>
    <near-scheme>
    <scheme-name>processNear</scheme-name>
    <front-scheme>
    <local-scheme>
              <service-name>ProcessFrontService</service-name>
         <eviction-policy>LRU</eviction-policy>
         <high-units>10000</high-units>
         <expiry-delay>10m</expiry-delay>
         <flush-delay>5m</flush-delay>
    </local-scheme>
    </front-scheme>
    <back-scheme>
         <distributed-scheme>
         <service-name>ProcessBackService</service-name>
         <backing-map-scheme>
         <local-scheme>
                        <service-name>ProcessBackLocalService</service-name>
         </local-scheme>
         </backing-map-scheme>
         <local-storage system-property="tangosol.coherence.processNode">false</local-storage>
         <autostart system-property="tangosol.coherence.processNode">false</autostart>
         </distributed-scheme>
    </back-scheme>
    <invalidation-strategy>present</invalidation-strategy>
    <autostart system-property="tangosol.coherence.processNode">false</autostart>
    </near-scheme>
    <near-scheme>
    <scheme-name>outputNear</scheme-name>
    <front-scheme>
    <local-scheme>
         <service-name>OutputFrontService</service-name>
                   <eviction-policy>LRU</eviction-policy>
                   <high-units>100</high-units>
                   <expiry-delay>5m</expiry-delay>
                   <flush-delay>1m</flush-delay>
    </local-scheme>
    </front-scheme>
    <back-scheme>
         <distributed-scheme>
         <service-name>OutputBackService</service-name>
         <backing-map-scheme>
                        <read-write-backing-map-scheme>
                        <internal-cache-scheme>
                        <local-scheme>
                                  <service-name>OutputBackLocalService</service-name>
                             <eviction-policy>LRU</eviction-policy>
                             <high-units>1000</high-units>
                             <expiry-delay>10m</expiry-delay>
                             <flush-delay>1m</flush-delay>
                        </local-scheme>
                        </internal-cache-scheme>
                        <cachestore-scheme>
              <class-scheme>
                        <scheme-name>outputBackStore</scheme-name>
              <class-name>spring-bean:dataStore</class-name>
              </class-scheme>
                        </cachestore-scheme>
                        <write-delay>20</write-delay>
                        <write-batch-factor>1</write-batch-factor>
                        </read-write-backing-map-scheme>
         </backing-map-scheme>
         <local-storage system-property="tangosol.coherence.outputNode">false</local-storage>
         <autostart system-property="tangosol.coherence.outputNode">false</autostart>
         </distributed-scheme>
    </back-scheme>
    <invalidation-strategy>auto</invalidation-strategy>
    <autostart system-property="tangosol.coherence.outputNode">false</autostart>
    </near-scheme>
    </caching-schemes>
    </cache-config>
    Best regards
    Jan

    Hi Jan,
    you should not inject Coherence caches into Spring beans and Spring beans into Coherence-managed objects from the same bean-factory/application-context.
    If you want to do so, then you should use a parent application context to be used by Coherence-managed objects, and another (child or one that is initialized later) application context to define beans that have Coherence caches injected into them.
    You might want to look at Spring classes containing SingletonBeanFactoryLocator in their names for easily defining multiple application contexts in a hierarchy.
    Best regards,
    Robert

  • 10 ms overhead when calling Thread.sleep on Linux

    Hi,
    I have been working on a traffic shaping simulation that requires me to send packets on a ms basis. When I call Thread.sleep(11) on Linux 2.4, I get a constant return around 30 ms. I tried to bypass the Thread.sleep function and called directly the select() function under linux with a timeout of 11 ms then I get a constant return around 20 ms. Then if I create a test.c program that loop 100 times calling the select(11), I get a very accurate rate around 10-11 ms. Anyone knows where that 10 ms overhead comes from? I tried executing the java program with Thread.sleep and the -XX:ForceTimeHighResolution but it doesn;t seem to change anything ! Any info would be very welcome ! Thanks

    Actually I get this behavior only on a machine with kernel 2.4. On a different machine with kernel 2.6 I get an accuracy of 10ms for a select call with 10 ms timeout. I know there was some improvements on the jiffy for kernel2.6 but I still don't get why calling select timeout 10ms from a C program return an accuracy of 10ms on linux 2.4 and the same select() timeout 10ms called from java return an accuracy of only 20 ms on kernel 2.4..... :( still looking

  • I can record voice memos fine using the built-in iPhone 4 mic.  And my Bluetooth headset (Jawbone Era) works fine when I leave messages on voice mail systems etc. when calling on the iPhone 4.  However, I cannot record voice memos with my Bluetooth mic.

    I can record voice memos fine using the built-in iPhone 4 mic.  And my Bluetooth headset (Jawbone Era) works fine when I leave messages on voice mail systems etc. when calling on the iPhone 4, so it appears my headset mic is fine.  I can also use voice activated dialing, although it fails miserably interpreting numbers.  However, I cannot record voice memos with my Bluetooth mic.   I just get barely audible static.  Any suggestions?   Thanks.

    Hello, did you ever get an answer to your question? I just picked up a Jawbone Era and using on an iPhone 4s running 5.0.1. Seems to work fine on regular calls, but not on the built in Voice memos application. It worked fine on my older Jawbone Icon, but haven't tested on the 4s or iOS 5.
    Thanks!

Maybe you are looking for