Are your ODP.NET clients connecting to TimesTen in direct mode or via client/server (I am guessing client/server)? What are your client side settings for TTC_TIMEOUT? Was the TT database actually loaded in memory when the clients tried to connect; if you have the default ramPolicy of inUse then the database gets loaded into memory from disk on the first application connection. If the database is large and./or your disks are slow then this could easily take longer than the TTC_TIMEOUT value resulting in the connection request timing out.
I suggest that you:
1. Switch the database to ramPolicy 'manual and then use ttAdmin -ramLoad to explicitly start it up.
2. Check your settings for TTC_TIMEOUT on the clients (the default is 60 seconds).
And of course, a network issue could also result in this kind of error.
Thanks a lot for your answer Chris.
Clients are connected by client/server.
Database is set on rampolicy to "always", because set it on "in use" spent a lot of time connection.
RAM residence policy: Always
Replication policy : Manual
Replication agent is running.
Cache Agent policy : Manual
Accessible by any group
End of report
TTC_TIMEOUT is set to 5 (secs) (because of the application response time)
Disk are SAN DISK (emc)
This is my database configuration.
Thanks for this information and also for the more comprehensive information that you provided offline. I have reviewed that and this looks to be a client side problem. There is no indication on the server side that there is any issue there, but the log messages
2014-06-28 15:54:45.71 Err : SRV: 17617: EventID=5| Socket recv() failed. Error (104): Connection reset by peer. File: /ade/vespa_20120924_kaiser-tt/timesten/VisiChannel/oc/src/vostcpip.cpp; Line: 668
indicate that the client side explicitly closed the connection while the server was waiting for a message from the client. This strongly suggests that there is some problem on the client side. Note that ODP.NET is a complex stack with several layers of which the TimesTen client is but a small part. It is certainly possible that there could be some issue with the TimesTen client but to my mind we should try and eliminate more general ODP.NET related issues first. I note that you have already seen this article about a problem with the same symptoms:
Have you tried the steps listed in that to see if they reveal any issue on the ODP.NET side? There is some limited debugging we could try and perform for the TimesTen client but it uses undocumented mechanisms so I would need to discuss that with you offline.