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 User updated by: ffortuny at gmail dot com 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.20 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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