Bug #68680 [Opn->Sus]: ibase_wait_event not returning correct event

Edit report at https://bugs.php.net/bug.php?id=68680&edit=1 ID: 68680 Updated by: cmb@php.net Reported by: ffortuny at gmail dot com Summary: ibase_wait_event not returning correct event -Status: Open +Status: Suspended Type: Bug Package: InterBase related Operating System: Linux Ubuntu 14.+ PHP Version: 5.5.9+dfsg-1ubuntu4.5 Block user comment: N Private report: N New Comment: The interbase extension is moved to PECL[1] as of PHP 7.4.0, and is looking for a new maintainer. Until a new maintainer is found, I suspend this ticket. Consider to use the bundled PDO_Firebird extension, or the php-firebird package[2] instead. [1] <https://pecl.php.net/package/interbase> [2] <https://github.com/FirebirdSQL/php-firebird> Previous Comments: ------------------------------------------------------------------------ [2015-05-27 20:12:05] cmb@php.net > Is there somebody in the world in charge of fixing this bug? Apparently, not (yet). It might be useful if you can make a patch or even better a pull request. > Otherwise, where is the source? The source of the interbase extension is available via Github: <https://github.com/php/php-src/tree/master/ext/interbase>. ------------------------------------------------------------------------ [2015-01-02 21:21:40] ffortuny at gmail dot com This is ONE work-around (it the case of 4 events): <?php header('Content-Type: text/event-stream'); header('Cache-Control: no-cache'); $idu=$_REQUEST["idu"]; $idc=$_REQUEST["idc"]; $con = ibase_connect(...) or die(json_encode(array("Error"=>ibase_errmsg()))); $ev0="noev0"; $ev01="noev01"; $ev02="noev02"; $ev03="noev03"; $ev04="noev04"; $ev05="noev05"; $ev06="noev0"; $ev1="newmsgi".$idu; $ev2="usrin".$idc; $ev3="usrout".$idc; $ev4="chat".$idu; $ev = ibase_wait_event($ev1,$ev0,$ev2,$ev01,$ev3,$ev02,$ev4); error_log("Evento regresado el idu ".$idu." idc ".$idc.": ".$ev); /* $ev1 = $ev1 $ev0 = $ev2 $ev2 = $ev3 $ev01 = $ev4 */ switch($ev){ case $ev1: $sql="sata: {$m}\n\n"; flush(); } break; case $ev0: $sql="select f flush(); break; case $ev2: $sql="sel flush(); break; case $ev01: $sql="sele flush(); break; } ?> as you can see in the code above, the REAL events the database Firebird sends are: $ev1, $ev2, $ev3 and $ev4 However, ibase_wait_event receives them in a different order: $ev1 goes to $ev1 (no change) $ev2 goes to $ev0 (3rd goes to 2nd) $ev3 goes to $ev2 (5th goes to 3rd) $ev4 goes to $ev01 (7th goes to 4th) There is a patter there; but this is about catching events, not about figuring out patterns. Is there somebody in the world in charge of fixing this bug? Otherwise, where is the source? ------------------------------------------------------------------------ [2014-12-31 16:28:44] ffortuny at gmail dot com This is the ibase php version that is failing to properly catch and retrieve the events sent by the database:5.4.6-0ubuntu5. ------------------------------------------------------------------------ [2014-12-31 08:17:43] ffortuny at gmail dot com the instruction in PHP: $ev = ibase_wait_event($rsc,$ev1,$ev2); Is now capable of receiving properly ONLY the first event in the list that the function is supposed to accept. In this case, $ev2 will never be transferred as a value to $ev. This is a serious matter and it needs to be fixed ASAP; there might be a number of applications receiving messages from the server; such messages are generated as the ibase_wait_event() function DOES RECEIVE an event call from the Firebird database. What happens now is that all those “servers” running, will remain running even long after the client has been disconnected, because the only way for them to die is by trying to send the client a message and NOT FINDING the client. ibase_wait_event stops execution of the PHP task and remains idle until Firebird does POST an event. So, it is mandatory that this function works properly for Firebird SQL server to be fully functional with PHP programming. ------------------------------------------------------------------------ [2014-12-29 06:37:58] ffortuny at gmail dot com This bug is especially difficult to test in actual working conditions, because it needs: 1. The application running with at least 2 users 2. both users must be connected to the same entity (corporation in the ERP) 3. both users must try all 4 instances to generate the posted events 4. the error log of the server serving the application must be monitored to check for the actual values being returned by PHP The values need to be a PHP problem simply because they are the result of Firebird Triggers after insert/delete which are definitely doing what they are supposed to do, as they have been checked with the same function, one by one. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=68680 -- Edit this bug report at https://bugs.php.net/bug.php?id=68680&edit=1