I'm using beanstalkd to queue some work to be processed remotely on my company. The server is on the internet (public ip) but the consumers are behind adsl lines remotely. So there is a linux as client going out through a dynamic ip and connecting to the server to get a job. It's all PHP and I'm using pheanstalk library on client.
Everything runs smoothly for some time, but then the adsl changes the IP (every 24h hours the provider forces a reconnect) the client just hangs, never to go out of "reserve".
I thought that putting a timeout on the reserve would help it, but it didn't. As it seems, the client issues a command and blocks, it never checks the timeout. Even with reserve-with-timeout (instead of a simple reserve) it is the servers responsibility to return a TIME_OUT as the timeout occurs. The problem is, the connection is broken and the client will stay blocked reading, it will never return. Is this a specific problem os pheastalk or is it inherent to the protocol? How could I detect the stale connection and force a reconnect? (maybe some kind of keepalive)
I have temporarily solved this problem making a vpn between the client and the server, so that the IPs of each end of the connection never change, even if the dynamic ip changes and the vpn reconnect.
But I still would be interested in knowing if this is an expected behaviour of the protocol.
This is the expected behavior of TCP/IP. When no data is sent over the
wire, TCP can not detect the connection is broken after the IP is changed.
The only option is set SO_TIMEOUT on the connection to beanstalkd. Usually,
you can set it larger than the timeout value of reserve operation, so the
connection is not timed out prematurely.
On Sat, Jul 14, 2012 at 10:53 AM, Andre Ruiz <andre.r...@gmail.com> wrote:
> I have temporarily solved this problem making a vpn between the client and
> the server, so that the IPs of each end of the connection never change,
> even if the dynamic ip changes and the vpn reconnect.
> But I still would be interested in knowing if this is an expected
> behaviour of the protocol.
> To post to this group, send email to beanstalk-talk@googlegroups.com.
> To unsubscribe from this group, send email to
> beanstalk-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beanstalk-talk?hl=en.
I understand this is expected behaviour of tcp/ip, what I didn't know
is if this is intended behaviour of beanstalk clients. I could't find
any references on setting so_timeout on pheanstalk, I'll keep looking.
I guess the protocol or the clients should have a bultin protection
for that, it seems fragile for when client and server are distant over
the internet.
On Mon, Jul 30, 2012 at 4:28 AM, Zhu Han <schumi....@gmail.com> wrote:
> This is the expected behavior of TCP/IP. When no data is sent over the wire,
> TCP can not detect the connection is broken after the IP is changed.
> The only option is set SO_TIMEOUT on the connection to beanstalkd. Usually,
> you can set it larger than the timeout value of reserve operation, so the
> connection is not timed out prematurely.
> best regards,
> 韩竹(Zhu Han)
> 坚果云, 最简捷易用的云存储
> 无限空间, 文件同步, 备份和分享!
> On Sat, Jul 14, 2012 at 10:53 AM, Andre Ruiz <andre.r...@gmail.com> wrote:
>> I have temporarily solved this problem making a vpn between the client and
>> the server, so that the IPs of each end of the connection never change, even
>> if the dynamic ip changes and the vpn reconnect.
>> But I still would be interested in knowing if this is an expected
>> behaviour of the protocol.
>> To post to this group, send email to beanstalk-talk@googlegroups.com.
>> To unsubscribe from this group, send email to
>> beanstalk-talk+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/beanstalk-talk?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "beanstalk-talk" group.
> To post to this group, send email to beanstalk-talk@googlegroups.com.
> To unsubscribe from this group, send email to
> beanstalk-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beanstalk-talk?hl=en.
-- Andre Ruiz <andre.r...@gmail.com>
Curitiba, PR, Brasil
Tel +55 (41) 8407-3847
