[rabbitmq-discuss] Long timeout if server host becomes unreachable

[Oleg Lyalikov]

Thanks Michael,

Unfortunately SocketFrameHandler#close invokes "flush" method which then
blocks again:

Thread [Thread-0] (Suspended)
    waiting for: BufferedOutputStream  (id=26)
        owned by: Thread [main] (Suspended)
    BufferedOutputStream.flush() line: 140
    DataOutputStream.flush() line: 123
    SocketFrameHandler.flush() line: 142
    SocketFrameHandler.close() line: 147
    Send$2.run() line: 131
    Thread.run() line: 724

I looked at the implementation of the write timeout in ActiveMQ, here it is:
http://opensourcejavaphp.net/java/activemq/org/apache/activemq/transport/WriteTimeoutFilter.java.html

The solution they use looks workable - it seems they register socket write
start time + keep boolean whether writing occurs right now and then check
in the separate thread

long delta = (filter.getWriter().isWriting() &&
writeStart>0)?System.currentTimeMillis() - writeStart:-1;

if delta is greater than write timeout they do socket.close().

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).
By the way do you know why SocketFrameHandler#close method invokes "flush"
first before making socket.close()? Is it ok in case of write timeout just
do socket.close() without flush?

As for modifying SocketFrameHandler so that it will use locks with timeouts
- that could be possible but with the same drawbacks as the solution above.

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. Could you provide some ticket link so that we
can monitor its status?

Thanks,
Oleg

2013/10/8 Michael Klishin [via RabbitMQ] <
ml-node+s1065348n30323h50 at n5.nabble.com>

>
> On oct 8, 2013, at 2:11 p.m., Oleg Lyalikov <[hidden email]<http://user/SendEmail.jtp?type=node&node=30323&i=0>>
> wrote:
>
> > For me the client should have possibility to set such timeout or at
> least have some workaround - I don't see any now.
>
> Oleg,
>
> I understand your frustration. I will file a bug about this.
>
> It should be possible to getFrameHandler on a connection and close its
> underlying
> socket with SocketFrameHandler#close. It does not write any data and
> catches
> any exceptions that may arise. It also does not use the output stream
> which is
> what SocketFrameHandler#writeFrame synchronizes on.
>
> So try detecting that the peer is gone in your own code (note: this is
> *the* fundamental
> issue here, not that JDK sockets don't have a timeout API) and close the
> socket.
> I cannot tell if that may cause the write method to throw but it's worth
> trying.
>
> Another relatively unintrusive option I can think of is modifying
> SocketFramehandler to use a lock that supports timeouts. This way it would
> be
> easier to detect the issue and instantiate a new connection.
>
> MK
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=30323&i=1>
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
> *signature.asc* (506 bytes) Download Attachment<http://rabbitmq.1065348.n5.nabble.com/attachment/30323/0/signature.asc>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://rabbitmq.1065348.n5.nabble.com/Long-timeout-if-server-host-becomes-unreachable-tp30275p30323.html
>  To unsubscribe from Long timeout if server host becomes unreachable, click
> here<http://rabbitmq.1065348.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=30275&code=b2xlZy5seWFsaWtvdkBnbWFpbC5jb218MzAyNzV8MzI1NzkxMjU5>
> .
> NAML<http://rabbitmq.1065348.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/Long-timeout-if-server-host-becomes-unreachable-tp30275p30338.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131008/6376e8d4/attachment.htm>