Bug #68680 [Opn]: 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 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: > 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>. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2014-12-29 06:17:22] ffortuny at gmail dot com Description: ------------ --- From manual page: http://www.php.net/function.ibase-wait-event --- $con=gldbConnect(); $ev1="newmsgi".$idu; $ev2="usrout".$idc; $ev3="usrin".$idc; $ev4="chat".$idu; $ev=ibase_wait_event($con,$ev1,$ev2,$ev3,$ev4); error_log($ev1."-".$ev2."-".$ev3."-".$ev4."- de base: ".$ev); Test script: --------------- $con=gldbConnect(); $ev1="newmsgi".$idu; $ev2="usrout".$idc; $ev3="usrin".$idc; $ev4="chat".$idu; $ev=ibase_wait_event($con,$ev1,$ev2,$ev3,$ev4); error_log($ev1."-".$ev2."-".$ev3."-".$ev4."- de base: ".$ev); In this code, the Firebird Database posts events depending on any one of 4 possible table inserts or updates. $ev1 "newmsgi".$idu is generated when a new message is sent to user $idu. This works fine all the time. Is it because it is the first argument? If usrin or chat happen, then ibase_wait_event reports "usrout"; if usrout happens, ibase_wait_event reports NOTHING (does not end anything to the error_log) Expected result: ---------------- the expected result is that when this code is executed: $con=gldbConnect(); $ev1="newmsgi".$idu; $ev2="usrout".$idc; $ev3="usrin".$idc; $ev4="chat".$idu; $ev=ibase_wait_event($con,$ev1,$ev2,$ev3,$ev4); error_log($ev1."-".$ev2."-".$ev3."-".$ev4."- de base: ".$ev); the above code is executed, $ev will take the value of the actual event that Firebird Sent. This was OK in versión 5.3 of PHP. As I just Actual result: -------------- $ev1 "newmsgi".$idu is generated when a new message is sent to user $idu. This works fine all the time. Is it because it is the first argument? If usrin or chat happen, then ibase_wait_event reports "usrout"; if usrout happens, ibase_wait_event reports NOTHING (does not send anything to the error_log) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=68680&edit=1