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

[Oleg Lyalikov]

Yes, I used heartbeats with low value, the stack trace for that thread was
in my first post, it is blocked on the same write action:

"pool-2-thread-1" prio=10 tid=0xac167000 nid=0x2c60 waiting for monitor
entry [0xac77d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:94)
        - waiting to lock <0xb4532608> (a java.io.BufferedOutputStream)
        at java.io.DataOutputStream.writeByte(DataOutputStream.java:153)
        at com.rabbitmq.client.impl.Frame.writeTo(Frame.java:189)
        at
com.rabbitmq.client.impl.SocketFrameHandler.writeFrame(SocketFrameHandler.java:137)

        - locked <0xb45325f0> (a java.io.DataOutputStream)
        at
com.rabbitmq.client.impl.HeartbeatSender$HeartbeatRunnable.run(HeartbeatSender.java:133)

        at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

I understand that connection can be easily used from different threads (and
we actually use it that way) but there should be possibility to close
connection in such blocked socket.write operation. As I mentioned ActiveMQ
has such setting, there was the same socketWrite0 blocking call and they
have a solution (it's open source so could be checked if it is suitable for
RabbitMQ).

For me the client should have possibility to set such timeout or at least
have some workaround - I don't see any now.

Oleg

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

> On oct 8, 2013, at 1:49 p.m., Oleg Lyalikov <[hidden email]<http://user/SendEmail.jtp?type=node&node=30321&i=0>>
> wrote:
>
> > So for me it looks like the RabbitMQ client library should provide
> possibility to set such write timeout - maybe using the same Heartbeat
> thread (for now this thread is blocked on "writeFrame" method like all
> other threads waiting freeing the lock on outputStream object).
> >
> > By the way I still cannot imagine any workaround for this issue but it's
> really critical for us. Do you think there are some?
>
> Have you tried using heartbeats with a low value (say, single digit
> seconds)? It was created
> exactly for the case when a peer goes away and TCP retransmission covers
> the fact.
>
> RabbitMQ Java client pretty much has to synchronize writes to the socket.
> You can share connection
> between threads w/o realizing so, e.g. by publishing from a consumer
> callback such
> as handleDelivery.
>
> MK
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=30321&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/30321/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-tp30275p30321.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-tp30275p30322.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/f3c477fa/attachment.htm>