[rabbitmq-discuss] Long timeout if server host becomes unreachable
oleg.lyalikov at gmail.com
Tue Oct 8 16:39:06 BST 2013
> > If "_socket" field is not private in SocketFrameHandler I could try
> overriding "close" method and invoke just _socket.close() - maybe that
> would help. But the field is private (maybe we can copy/paste the class and
> instantiate our new one but it does not look good - it would be better to
> just enhance existing functionality not to replace - there could be some
> problems with compatibility with newer versions of RabbitMQ client lib,
> RabbitMQ tests should be run regularly as our own tests, etc).
> I understand the desire to avoid deploying a fork. However, it's already
> clear that the client
> needs to be modified somehow and you have a way to reliably reproduce the
> problem (is this correct?)
> Perhaps the fastest turnaround time would be for you to make some changes
> and try them out.
> Once a solution that works is found, we will see if it can be incorporated
> into the mainline.
Reproducing is not too hard - we have 2 virtual machines and just turn
network off on the one machine when needed (maybe there is a better way but
that was pretty enough).
There is also possibility to not make copy/paste of SocketFrameHandler - we
managed to get Socket object through the reflection and invoking
socket.close() really caused the "socketWrite" method to throw an Exception
- what was desired. The last thing to do is registering write start time
and whether write is occurring right now - and separate thread can
successfully close socket when timeout expires.
We also have another specific solution - actually the problem appeared in
our HA configuration and components connected always to the "primary"
RabbitMQ host (with possibility to switch to backup and vice versa). When
primary host is shutdowned we observe this behavior. So now we want to try
to connect to "localhost" RabbitMQ first, we have an HA configuration
between RabbitMQ servers though we didn't do much tests with it but we hope
that solution can solve the problem for the majority of the cases. But
still blocked write can arise in some cases.
So we keep first solution in mind but for now it's unknown if we will make
fix. If we do we will share it so that it can help faster incorporating
into the library.
> > Both workarounds require careful testing and time, we will think about
> it. But I'm hoping RabbitMQ library will provide functionality to set
> socket write timeout in the future.
> You can help with that. Contributing does involve submitting a CLA but
> digital ones
> are accepted.
> > Could you provide some ticket link so that we can monitor its status?
> rabbitmq bug tracker is not public but we accept issues that are filed on
> github, so I filed
> one you can watch:
Thank you very much for all your help,
View this message in context: http://rabbitmq.1065348.n5.nabble.com/Long-timeout-if-server-host-becomes-unreachable-tp30275p30344.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss