'Predis_ClientException' with message 'Cannot assign requested address'

[starinacool]

I'm using predis and from time to time I have these messages in php.err:

PHP Fatal error: Uncaught exception 'Predis_ClientException' with message
'Cannot assign requested address' in /home/meshok/predis.php:648
Stack trace:
#0 /home/meshok/predis.php(708): Predis_Connection->connect()
#1 /home/meshok/predis.php(680): Predis_Connection->getSocket()
#2 /home/meshok/predis.php(116):

Predis_Connection->writeCommand(Object(Predis_Commands_SetAdd))
#3 /home/meshok/predis.php(124):

Predis_Client->executeCommandInternal(Object(Predis_Connection),
Object(Predis_Commands_SetAdd))
#4 /home/meshok/predis.php(108):

Predis_Client->executeCommand(Object(Predis_Commands_SetAdd))
#5 [internal function]: Predis_Client->__call('sadd', Array)
#6 /home/meshok/bounce.php(55): Predis_Client->sadd('emails_550',

'storm@radioener...')

What version of the product are you using? On what operating system?
redis 1.2.2 32 bit on 64 bit debian

What can couse that

[nrk]

It is not really that easy to spot the actual cause without further details but it does not seem a bug related to Predis, more something related to the underlying system (the error is generated when the subsystem tries to open the socket resource).

Sometimes the "Cannot assign requested address" error can be seen when running out of file descriptors / available TCP ports: are you sure your server is properly configured to handle the current load? If you happen to see a huge number of connections in a TIME_WAIT state by running the following command:

netstat -n | grep TIME_WAIT | wc -l

then you might need to tune your server. Maybe you can try increasing the number of ephemereal ports configured for the TCP stack or setting the TIME_WAIT reuse with /proc/sys/net/ipv4/tcp_tw_reuse, lowering the FIN timeout is a last resort. These are just a couple of ideas, remember to review them according to your current server configuration and the services that are running on it. Check also for the presence of relevant errors in /var/log/messages.

[starinacool]

I made some investigation and found out that after every command Predis reconnects to the server. I understood that when I saw redis-cli INFO command output. The number of command proccessed was the same as the number of connections established.

I dig in to Predis and disable this line in Predis_Connection class (in __destruct() ):
632: #$this->disconnect();

After this predis do not disconnect after every command. This solved my problem.

Why Predis calls this method after every command?

P.S. I'm using Predis for PHP for 5.2

P.S.2 What number of connections in TIME_WAIT state is considered to be huge? I have 1500 at this moment.
Thanks.

[nrk]

Sounds strange, Predis_Connection::__destruct is called by the PHP engine only when the script terminates or when an instance of that class goes out of scope (but it can't go out of scope because Predis_Client or Predis_ConnectionCluster always holds a reference to it).

Just to be sure, I traced all method invocations while issuing multiple commands to redis and Predis_Connection::__destruct is indeed called one time only when the script terminates (I use xdebug for tracing). On a side note, Predis does not support persistent connections which means that the socket is automatically closed by PHP when the script terminates its execution, thus removing the code in the destructor should not actually change much. If your script send only one command to redis on each execution, than that should be the reason why you get num. commands == num. connections in reply to INFO.

Which exact version of the PHP 5.2 interpreter are you using? How does your script look like (e.g. how many commands are sent to redis on each execution)? Which webserver are you using and how is it configured to run PHP (FCGI, ModPHP, ...)?

By the way 1500 connections in a TIME_WAIT state is quite high (not huge, but neither low). You can try enabling the TIME_WAIT reuse (search for TCP_TW_REUSE for informations) for the TCP stack with this command:

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

See if it alleviates the problem when running with the vanilla Predis client. If everything goes well, you might want to persist that setting upon reboot by adding the following line in /etc/sysctl.conf :

net.ipv4.tcp_tw_reuse = 1

[starinacool]

I have found the problem.

zend.ze1_compatibility_mode was set to true in my config.

[nrk]

As a matter of fact, I have never tested Predis with the zend.ze1_compatibility_mode enabled but after a quick test I can confirm that it causes weird issues. I think that the way to go is to actually leave everything as is by declaring Predis incompatible with environments running on PHP 5.2 with zend.ze1_compatibility_mode turned on (which, by the way, is not even supported on PHP 5.3 anymore).

In the next few days I will add a note about zend.ze1_compatibility_mode in the documentation, in the meanwhile I'm closing this issue as resolved. Thanks for your collaboration, it is greatly appreciated!