org.vertx.java.core.eventbus.ReplyException

489 views
Skip to first unread message

蒋震宇

unread,
May 31, 2014, 7:22:59 AM5/31/14
to ve...@googlegroups.com
Hi,all:

In a cluster environment, eventbus often disconnected, "org.vertx.java.core.eventbus.ReplyException", no other errors in program code, reasons could not be found.

Would you please tell me that what may cause this problem and how to troubleshoot it.

Version: 2.1RC3 and 2.1,Based Java .

Tim Fox

unread,
May 31, 2014, 8:12:36 AM5/31/14
to ve...@googlegroups.com
The failureType field of that exception should give you more information.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

蒋震宇

unread,
May 31, 2014, 8:33:45 AM5/31/14
to ve...@googlegroups.com
I have some nodes deployed on multiple servers,use  "eventBus.sendWithTimeout"  but have error sometimes , the  error appears in the different nodes,The full error like this:

Tim Fox

unread,
May 31, 2014, 9:07:19 AM5/31/14
to ve...@googlegroups.com
As I said in my last post, look at the failureType field of the exception.

Jordan Halterman

unread,
May 31, 2014, 9:18:13 AM5/31/14
to ve...@googlegroups.com
You should look at the exception type. There are a few reasons this can occur:
- No handlers registered at that address
- Reply timed out
- User code replied with an exception (by triggering a failure on the received Message)

You can get the exception type from the ReplyException.

((ReplyException) result.result()).failureType() I think is the right way do to it if I remember correctly (sorry I'm not at a computer to look it up right now). You can use that to inspect the exception to determine which of those three types it is.

Since you mentioned this happens in a clustered environment, I would suspect your cluster is not set up correctly so handlers are not being propagated across the cluster.
--

Jordan Halterman

unread,
May 31, 2014, 9:19:59 AM5/31/14
to ve...@googlegroups.com
By the way, that does *not* indicate that the event bus is disconnected. It's simply an issue where either the handler you're sending a message to doesn't exist or you're expecting a reply that never comes.

On May 31, 2014, at 4:22 AM, 蒋震宇 <fy52...@gmail.com> wrote:

--

Jordan Halterman

unread,
May 31, 2014, 9:20:38 AM5/31/14
to ve...@googlegroups.com
Gah sorry my phone didn't tell me there were more messages :-) stupid phone

On May 31, 2014, at 4:22 AM, 蒋震宇 <fy52...@gmail.com> wrote:

--

蒋震宇

unread,
May 31, 2014, 9:35:49 AM5/31/14
to ve...@googlegroups.com
Thank you for your reply. The failureType is "NO_HANDLERS", but this handler exists. In some cases Vertx will remove handler ?

蒋震宇

unread,
May 31, 2014, 9:49:19 AM5/31/14
to ve...@googlegroups.com
Cluster.XML is based on hazelcast-default.XML, just modify the following:

<join>
    <multicast enabled="false">
        <multicast-group>224.2.2.3</multicast-group>
        <multicast-port>54327</multicast-port>
    </multicast>
    <tcp-ip enabled="true">
        <interface>10.80.11.235</interface>
        <interface>10.80.11.236</interface>
        <interface>10.80.11.237</interface>
        <interface>10.80.11.238</interface>
        <interface>10.80.11.239</interface>
    </tcp-ip>
</join>

As you say, the node does not disconnect (multiple eventbus a node registered, when sometimes an event has error , other events is normal).

Thanks.

Tim Fox

unread,
May 31, 2014, 2:33:56 PM5/31/14
to ve...@googlegroups.com
On 31/05/14 14:35, 蒋震宇 wrote:
Thank you for your reply. The failureType is "NO_HANDLERS", but this handler exists. In some cases Vertx will remove handler ?

This means, that at the time of sending the sending node had no knowledge of any handlers for that address anywhere on the cluster. This could be because

a) You haven't registered any handlers for that address anywhere
b) You haven't let information of the handlers propagate across the network
c) Target node has died so knowledge of its handlers has been removed

蒋震宇

unread,
Jun 3, 2014, 12:47:56 AM6/3/14
to ve...@googlegroups.com
Thank you for your reply, I'm sure:

1. Handler is already registered
2. Network is working correctly
3. Program is not closed (normal operation of the other events are the same instance)

My environment may have some special:There is more than one service (for example, persistence, task scheduling) running in a cluster, we developed applications to access these services, regular debug (debug use "org.vertx.java.platform.impl.cli.Starter").

This means that the nodes will often connect/disconnect clusters. It will  causes NO_HANDLERS? (By the way, where the handler of the service has been running, there is no exit)?

Sorry ,my English is poor.

Jon Arne Hegge

unread,
Apr 24, 2015, 7:42:59 AM4/24/15
to ve...@googlegroups.com
Hi all!

i think we are discussing the same issue here :

Reply all
Reply to author
Forward
0 new messages