Flemming, The errors you mention don't match our problems in detail... but a lot of what you seem to be describing of late matches what we have been observing. We are on Windows 2000 (both client and server).
What does your application do ? We do a lot of web pages where you Open/Query/Close and Open/Insert/Close dozens of times a minute (sometimes hundreds). All kinds of socket / buffer / odd concurrency issues have turned up. Our programs that *Open/run all day/close on close* work great... it is the frequent opening / closing that seems to expose a lot of issues in the drivers, XServer, etc. Do you have access to a Windows XP / Windows 2000 system - I'm curious if the "stress test" dotNet application I posted before generates against a Linux server. I have VMWare to install SAPDB under Linux, but I haven't had the time to do it yet. I just wanted to point out that the general issues you describe - instability that shows up as memory / resource leaks - we have seem similar symptoms. We have not had much luck getting them down to easily reproducible situations. Like you, it often hits us after 24 hours (or even 6 or 8 days). I will note that the big thing we did was shifted from "same server" (ServerNode= not present on connection) config to two separate machines... and the quality of our SAPDB experience dropped like a rock. We ran for 18 months without many problems and we see all kinds of odd problems now that we introduced a network (cross over cable) between database and application :( We have two separate installs in two separate cities, we see the problem in both instances. One of the things I want to fiddle with when I have time is to simulate packet 5% loss between a SAPDB server and SAPDB client (driver). I have some fears that oddball network problems can end up producing some really bad responses. Blocking behavior (one client request stalling all others) has been noted in the list archives. Maybe some new problem has been introduced in recent versions that invalidates the good behavior of SAPDB we had in the past? Your references to older code working better is something we have contemplated (setting up lab systems with older releases in the 7.3.0.18 timeframe to see if problems we are seeing now exist).... Stephen Gutknecht -----Original Message----- From: Flemming Frandsen [mailto:ff@;partyticket.net] Sent: Wednesday, November 06, 2002 12:58 PM To: SAPDB Subject: Error connecting to database I have a webapplication that re-uses database connections across web-requests, in general it works ok. The database server is: Kernel = Kernel 7.3.0 Build 029-000-087-800 Runtime Environment = X32|LINUX 7.3.0 Build 029-000-087-800 I tried the odbc interface lib that came with that build, but I found that it started failing during connect with "Unable to create communication semaphore" (or some such) after only 1-2 hours of light load, to clear the error I had to stop the x_server and start it again. Stopping and starting the clients didn't do any good at all. The DSN used with the 7.3.0.25 version of the driver, was 127.0.0.1:ZDB, using :ZDB or localhost:ZDB caused a segfault during connect. I've gone back to using an extremely old (7.3.0.17) version that was compiled with debug, it seems to be stable, but after a while, typically 24h of fairly light load, new connections to the database start to fail with: [SAP AG][LIBSQLOD SO][SAP DB]Unable to connect to data source;-709 CONNECT: (cannot create reply fifo). (SQL-08001)(DBD: db_login/SQLConnect err=-1) The DSN used was :ZDB not 127.0.0.1:ZDB as used with the new version, so that might be a source of the differences. Everything runs on x86 Linux. I'm not using a driver manager, the DBD::ODBC driver was compiled directly against the sapdb odbc lib, so if I'm the only one doing this then that may the reason for the instability I'm seeing here. Have anyone seen errors like these? It may be a good idea to make it possible to build sapdb with electric fence: ftp://ftp.perens.com/pub/ElectricFence/ElectricFence-2.1.tar.gz it's an implementation of malloc that places the end of the memory allocated just before an inaccessible page, so that any overflowing writes will cause a segfault on the exact instruction that caused the error, this is great for debugging. -- Regards Flemming Frandsen - http://dion.swamp.dk PartyTicket.Net co founder & Yet Another Perl Hacker _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
