ID: 13515 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: OCI8 related Operating System: Linux (redHat) PHP Version: 4.0.4 New Comment:
I have a similar error but on a different setting and would like to know if this could be related. We have a ora-600-[711] error which Oracle say is a network issue and related to how php communicate with it. We use PHP 4.11, running on Window NT with both Oracle & PHP in the same box (so network should not be an issue) and using OCI and the problem keeps repeating, especially when the system has medium usage, on 3 different servers with clean NT. Please do you have any idea what cause this? thanks in advance, Phillip Previous Comments: ------------------------------------------------------------------------ [2001-10-02 13:30:02] [EMAIL PROTECTED] this is indeed an oracle-bug. i have implemented a workaround which will be in 4.0.7. some oracle-guy told me they fixed the crash in oracle against an error-message in 8.1.7.2. please use 4.0.7RC2 or current CVS. ------------------------------------------------------------------------ [2001-10-02 12:21:04] [EMAIL PROTECTED] We are running a large website using several machines with also different os, apache and php versions. We encountered a problem with "hanging" apache server prozesses (that will not quit on gracefull only on real restarts) as well as ORA-600 errors on database server (Oracle 8.1.6.1) under extreme website load or in conjunktion with unoptimized queries or when restarting a couple of webservers simultanous, quitting a large number of such hanging prozesses. Oracle Support claims the ORA-600 [16365] Error (an internal oracle error) on an flaw of their OCI library: This is their answer to a similar case like ours filed Mid July 2001: ================================== The main reason we are focusing on the client side is because the error generated on the server is caused by a message that was sent out of turn from the client. This is a half protocol violation error caused by the client. . Basically it means the client sent the server a message and instead of waiting for the reply it decided to send another message out of turn. In other cases of this where the apache server was the oracle client, under heavy load the apache server has a request timeout of 5 minutes. If the server becomes heavily used and in this case starts paging and swapping it is possible for it not to respond for this timeout period. What happens now is the apache server times the request out. It has a signal handler which, unfortunately, then long jumps out of oracle client library code (oci) leaving the read system call to the server. Also leaving the client side library code in an unknown state, therefore causing any number of possible problems. . Then the client application unaware of the longjmp by the apache server would try a request to the oracle server using the same session and cause this half protocol violation. Note this error is only generated by the MTS server. . If however, from the above information the connection to the oracle server is not from the web server then the problem will be caused by whatever other application happens to be using to access the database. . As oracle has no control over long jump outs of it's code the only way to drop a connection in this situtation is for the client to send an OCIBreak/OCIReset. ANy other request will cause the error that is seen above. . Therefore by increasing the timeout we reduce the possibility of longjmps out of the oracle client library. ALso the application can be modified to send an OCIBreak/OCIReset to the server. The people that wrote the PHP scripting language apparently put a modification in their code to cope with this. However, I have not seen this change so I cannot comment on it. =================== I could not find any break or reset instructions in the code of oci8.c nor any informations in mailinglist and bugdatabase, but I'm a lousy c programmer and maybe the problem was fixed in the latest version, but I could not find any release notes dealing with that problem. I always though the error would be a Oracle error, but it as they say it seems to be a misshandling on client side code (in this case the webserver that acts client to the database) thanks ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=13515&edit=1
