Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.14.0

Bug #12406 Read timed out
Submitted: 2007-11-08 21:35 UTC
From: juhasev Assigned: yunosh
Status: Closed Package: SOAP (version 0.11.0)
PHP Version: 4.3.9 OS: Redhat ES4
Roadmaps: (Not assigned)    
Subscription  


 [2007-11-08 21:35 UTC] juhasev (Juha Vehnia)
Description: ------------ We will get read time out when returning array of object... Magically we can return 10 objects, but the 11th one will cause the problem. We can return any then out of 100 survey objects and we are good, returning more than 10 will cause the problem. $params = array('sessionkey' => $sessionkey); $response = client->call('getSurveyList',$params,$nsa); Each returned object looks like this: [0] => stdClass Object ( [SurveyId] => 373 [SurveyName] => 257 options pulldown [SurveyCreated] => 2007-11-08 09:33:16 [SurveyCreatedBy] => Jay Robinson [SurveyActive] => no ) This works fine with SOAP 0.10.0 but after an upgrade to SOAP 0.11.0 the Transport/HTTP.php line 511 triggers an error: return $this->_raiseSoapFault("Timed out read from $host"); The code here appears to be same between different versions. Somehow the number of objects or amount of data causes this to happen. Test script: --------------- Return array of these objects (count > 10) produces this error: /** * Class holds survey properties for SOAP access. * @package SOAP-Server */ class SoapSurvey { /** @var unsignedInt */ var $id; /** @var string */ var $name; /** @var created */ var $created; /** @var created */ var $createdby; /** @var active */ var $active; function SoapSurvey() { $this->id = NULL; $this->name = NULL; $this->created = NULL; $this->active = NULL; $this->createdby = NULL; } function setId($sid) { $this->id=$sid; } function setName($name) { $this->name=$name; } function setCreated($created) { $this->created=$created; } function setActive($active) { $this->active=$active; } function setCreatedBy($createdby) { $this->createdby=$createdby; } /** * Convert value to SOAP value. * @access private */ function getSoapObject() { global $SURVEY_NAMESPACE; $name = 'x_'.get_class($this); $values=array(); array_push($values,new SOAP_Value("\{$SURVEY_NAMESPACE}SurveyId",'unsignedInt',$this->id)); array_push($values,new SOAP_Value("\{$SURVEY_NAMESPACE}SurveyName",'string',$this->name)); array_push($values,new SOAP_Value("\{$SURVEY_NAMESPACE}SurveyCreated",'string',$this->created)); array_push($values,new SOAP_Value("\{$SURVEY_NAMESPACE}SurveyCreatedBy",'string',$this->createdby)); array_push($values,new SOAP_Value("\{$SURVEY_NAMESPACE}SurveyActive",'string',$this->active)); return new SOAP_Value ("\{$SURVEY_NAMESPACE}$name",'SoapSurvey',$values); } } Expected result: ---------------- List of survey objects. Actual result: -------------- Timed out read from $host

Comments

 [2008-04-21 09:18 UTC] coelhoric (Coelho Ricardo)
Hi, I have a bit the same problem. I created a server and clients with PEAR::SOAP. The server have to send a object with various members. In some cases, clients are stopped with a "Timed out read from XXX". I analyzed the SOAP code and I discovered the problem was "if ($it++ > 10)" in Base.php. Because of the content of my object, in some cases, i have a non-associative array with more than 10 values. So, there is a "raiseSoapFault". The problem is that the "$this->fault->message" (in Server.php, _sendReponse) is so huge (maybe because of my object) that Apache take too long time to generate the response. In consequence, the client is time out. Can you explain or "correct" the limitation ?
 [2008-07-12 18:54 UTC] doconnor (Daniel O'Connor)
A helpful code snippet from just above the offending line: // If someone has a large hash they should really be defining the type.
 [2008-07-12 18:59 UTC] doconnor (Daniel O'Connor)
I'm going to mark this as a Duplicate of Bug #14337
 [2008-07-15 00:44 UTC] yunosh (Jan Schneider)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Both issues have been fixed in CVS, we no longer include the backtrace in SOAP faults by default, which caused the timeouts, and we no longer limit the hash checking to 10 elements. You might still get timeouts, but now it will be your own fault, since you didn't use a SOAP_Value instead of letting the code detecting the type. ;-)