We are using SiebelDataBean to connect to Siebel EAIObjMgrAPI component using below process provided.
https://docs.oracle.com/cd/E14004_01/books/OIRef/Customizing_Siebel_Object_Interfaces12.html
The application works fine for a while and then start throwing below error, kindly let me know if anyone else has encountered this issue.
[CMGR WARNING] Received notification: The task 257950792 has either been shutdown or timed-out connection:f600448
Logon Request 106 on connection 2100445 was abandoned after 30001 ms because it timed out.(SBL-JCA-00317)
Check the SISNAPI idle timeout setting on the EAI component parameters. If there is no activity for that much seconds, the system logs out the session to preserve memory.
Related
I am using Apache Curator v4.3.0 (ZK v3.5.8), and I noticed that in some disconnect/reconnect scenarios, I stop getting a RECONNECTED event to the registered listener/s.
CuratorFramework client = ...;
// retry policy is RetryUntilElapsed with Integer.MAX_VALUE
// sessionTimeout is 15 sec
// connectionTimeout is 5 sec
client.getConnectionStateListenable().addListener(new ConnectionStateListener()...
Although I do see that the ConnectionStateManager prints the state change:
[org.apache.zookeeper.ClientCnxn] - Client session timed out, have not heard from server in 15013ms for sessionid 0x10000037e340012, closing socket connection and attempting reconnect
[org.apache.zookeeper.ClientCnxn] - Opening socket connection to server
...
[org.apache.curator.ConnectionState] - Session expired event received
[org.apache.zookeeper.ClientCnxn] - Session establishment complete on server
[org.apache.curator.framework.state.ConnectionStateManager] - State change: RECONNECTED
Usually right after I see my listener called on stateChanged, but not always.
The CuratorFramework client is shared between multiple components registering different listeners. I didn't see any restriction to have only one client per listener. But, when I don't share it, the problem doesn't occur anymore.
Any suggestions on how to proceed debugging this problem?
Thank you,
Meron
This appears to be the bug that was fixed in Curator 5.0.0 - https://issues.apache.org/jira/browse/CURATOR-525 - if you can please test with 5.0.0 and see if it fixes the issue.
We are using websphere application server 8.5.0.0. we have a requirement where we have to query a LDAP server to get the customer details. I tried to configure the connection pool as described here and here.
I passed the below JVM arguments
-Dcom.sun.jndi.ldap.connect.pool.maxsize=5
-Dcom.sun.jndi.ldap.connect.pool.timeout=60000
-Dcom.sun.jndi.ldap.connect.pool.debug=all
Below is a sample code snippet
Hashtable<String,String> env = new Hashtable<String,String>();
...
...
env.put("com.sun.jndi.ldap.connect.pool", "true");
env.put("com.sun.jndi.ldap.connect.timeout", "5000");
InitialDirContext c = new InitialDirContext(env);
...
...
c.close();
I have two issues here
When I am calling the service for the 6th time, I am getting javax.naming.ConnectionException: Timeout exceeded while waiting for a connection: 5000ms. I checked the connection pool debug logs and I noticed the connections are not returning back to the pool immediately despite closing the context safely in a finally block. The connections are released after some time and expired after sometime after the release. There after if I call the service again, it connects to the LDAP server but new connections are being created.
I tried to execute the code and I am able to see the connection pool debug logs. But the logs are being logged in System.Err log. Is this an issue? Can I ignore it?
But when I run the code as a standalone application(multithreaded with loop of 50 times), the connections are returned/released immediately.
Can anyone please let me know what am I doing wrong?
My problem is when i retrieve too many data from database and select using odbc node
when my workflow is run exception The timeout (30 secs) was exceeded while waiting for a response from DropPoint transactionRequest
Please help how to resize defalut timelimit of workflow.
The timeout you mention is the timeout on the connection that is using a DropPoint and not a timeout on the workflow as a whole.
From within the connections pane, open the connection you are using on the workflow and modify the timeout setting there.
Separate to this, if you're calling the workflow via rest api, you can set a timeout. To override the default there, add the query string: _timeout=300 to the url in your consuming app (i.e. Not in the endpoint url setting in Flowgear).
I'm fetching messages on background from IMAP server using performFetchWithCompletionHandler.
The first thing I do on method implementation is check for network reachability, discarding operation if its no available.
Then I start refresh process executing fetchMessagesOperationWithFolder on a IMAP session.
As result of this operation I usually receive no error, but sometimes I receive an MCOErrorParse (Unable to parse response from server), MCOErrorConnection (A stable connection to the server could not be established) or MCOErrorAuthentication (Unable to authenticate with the current session's credentials).
Can all this errors be produced due to connection failure?
I want to handle the MCOErrorAuthentication to notify user on the credentials error, but in this scenario the credentials are ok, so when I perform any operation when on foreground again with network reachability it will succeed.
Should I do an extra network connection check before proceed on those errors? Should I create a new IMAP session on every operation?
Thanks!
Edit
I'm adding ConnectionLog, it take me long to reproduce the error. Its very clear why I receive a MCOErrorAuthentation: I'm not loading password well.
2014-12-18 21:00:41.212 * OK Gimap ready for requests from 85.58.177.133 et58mb78762219web
2014-12-18 21:00:41.222 1 CAPABILITY
2014-12-18 21:00:41.302 * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN
1 OK Thats all she wrote! et58mb78762219web
2014-12-18 21:00:41.304 2 LOGIN “polferresamon#gmail.com" ""
2014-12-18 21:00:41.378 2 NO Empty username or password. et58mb78762219web
2014-12-18 21:00:41.380 Error fetching messages: Unable to authenticate with the current session's credentials.
So, to really solve MCOErrorAuthentication I have to check IMAP session init, and the process where I'm loading email and password when returning from background.
I guess parse and connection errors are due to connection issues.
Thanks for your help.
I'm getting a lot of errors about "Read timed out".
Caused by: org.apache.cxf.binding.soap.SoapFault: Read timed out
Is this error on yodlee's servers side?
How can this be fixed?
This is because the API is taking more time. You can override by setting
Java System parameter as “-Dcom.yodlee.soap.client.read.timeout="time out in milli sec" without quotes. Please configure it to 60 secs and see if it resolves.
If you are using CXF, you can control the client timeout by modifying the configuration for the client http-conduit file.