Handling of new client connections
|Reported by:||dmisev||Owned by:||dmisev|
#if 0 // client table is a relict from 1-process, multi-user rasdaman; // now it conflicts with rasmgr dispatcher mimics, so we disable -- PB 2005-sep-01 currentClientContext = new ClientTblElt( client, ++(clientCount) ); currentClientIdx = clientCount; #else // this id must be !=0 because otherwise in ServerComm::getClientContext() it will not be recognized as valid id, and then the "last action" time will not be updated (timeout!) #define SINGLETON_CLIENTID ULONG_MAX // disable client list by using only 1 element (fixed id), initialize only once currentClientIdx = SINGLETON_CLIENTID; // if (currentClientContext==NULL) currentClientContext = new ClientTblElt( client, currentClientIdx ); TALK( "using constant Client id " << currentClientIdx ); // make sure any old element is deleted; currently inhibited, crashes :( -- PB 2005-sep-02 // RMInit::logOut << "client table has " << clientTbl.size() << " elements before cleanup, "; // ServerComm::deleteClientTblEntry( currentClientIdx ); // RMInit::logOut << " and " << clientTbl.size() << " after."; #endif // 0
After a java request to rasdaman (e.g. WCPS), rasql is still seen as a java client, which later on can cause further troubles. Changing the #if 0 to #if 1 fixes this.
Change History (5)
comment:4 Changed 4 years ago by dmisev
- Priority changed from major to minor
- Type changed from defect to enhancement