| Title | Intermittent socket errors from TeamTrack 5.0 when using a database upgraded from TeamTrack 4.5 |
| Status | closed |
| Priority | critical |
| Assigned user | Gareth Rees |
| Organization | TeamShare |
| Description | When using a database that was created in TeamTrack 4.5 and then upgraded to TeamTrack 5.0, there are socket failures. The P4DTI hangs for a minute or so, then gets a socket error from the TeamShare API. The failures are intermittent: a test may succeed several times, then fail. The error message returned from the TeamShare API is as follows: SOCKET_READ_ERROR: Socket error. One reason might be database needs up upgrading. Check event view for complete error message. |
| Analysis | Each failure is preceded by a pause of around a minute or so. If I stop the execution during this pause, I get a stack trace like this: NTDLL! 77f682db() MSAFD! 776642b6() WS2_32! 776b8308() CSocket::Receive(void * 0x017449c0, int 8196, int 0) line 157 TSSocket::FillBuffer() line 583 + 29 bytes TSSocket::ReadChar() line 545 + 8 bytes TSSocket::ReceiveInt(int * 0x0012dcbc) line 600 + 8 bytes TSServer::Send(TSSocket * 0x09a4f670, const char * 0x0182b2c0, int 13465) line 485 + 12 bytes TSServer::UpdateRecord(TSRecord * 0x03e6c5f0, TSRecord * 0x03e6c5f0) line 4198 + 23 bytes teamtrack_record_update(_object * 0x08285300, _object * 0x0082312c) line 316 + 28 bytes PYTHON20! 002428e8() TEAMTRACK! struct _typeobject teamtrack_record_type address 0x0150c178 The API always hangs in CSocket::Receive, but it isn't always TSServer::UpdateRecord at the bottom; the problem can also occur in TSServer::ReadRecordListWithWhere. When CSocket::Receive eventually returns, it returns SOCKET_ERROR. The error code returned by WASGetLastError() is WASECONNRESET (connection reset). This strongly suggests that the problem is to do with the server: this could happen if the server failed in some way so that there was nothing on the other end of the socket. This occurs when using a database created in TeamTrack 4.5 and then converted to TeamTrack 5. The offending database is < http://www.ravenbrook.com/project/p4dt...c/2001-05-31/job000326/tmtrack-4509.mdb>. This does not occur when using a database newly created in TeamTrack 5. So perhaps the database is corrupt in some way.GDR 2001-06-30: TeamShare found a defect in the API that may be the cause of this [1]. |
| How found | manual_test |
| Evidence | [1] <http://info.ravenbrook.com/mail/2001/06/29/17-51-25/0.txt> |
| Observed in | 1.1.1 |
| Created by | Gareth Rees |
| Created on | 2001-06-12 15:15:11 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 19:45:32 |
| History | 2001-06-12 GDR Created. 2001-06-30 GDR Referred to defect found by TeamShare. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 13767 | closed | 2001-07-03 12:36:09 | Gareth Rees | Added support for TeamTrack 5.0: Split code/tsapi/... into code/tsapi-4.5/... and code/tsapi-5.0/... and split the Developer Studio project teamtrack.dsp into teamtrack-4.5.dsp and teamtrack-5.0.dspso that I can build two copies of the Python interface to TeamTrack, one for TeamTrack 4.5 and one for TeamTrack 5.0. Updated teamtrack-module.cpp so that it has two entry points (one for each module). Added teamtrack_version configuration parameter. Updated design, Administrator Guide and release notes. |