Me again - question about workers...

[bac...@gmail.com]

Hi,

I'm trying to develop a worker Verticle that needs to do out-of-process calls.

When I run the Verticle, everything works fine.

However, when I add the "-worker" switch to tell VertX to run it as a worker, I don't seem to be able to reply to any messages or publish to the event bus from within the Verticle without getting the following exception...

Exception in Java verticle script
java.lang.IllegalStateException: Cannot be used in a worker application
        at org.vertx.java.core.net.impl.DefaultNetClient.<init>(DefaultNetClient.java:61)
        at org.vertx.java.core.impl.DefaultVertx.createNetClient(DefaultVertx.java:106)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendRemote(DefaultEventBus.java:494)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendOrPub(DefaultEventBus.java:363)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendReply(DefaultEventBus.java:295)
        at org.vertx.java.core.eventbus.impl.BaseMessage.reply(BaseMessage.java:53)
        at org.vertx.java.core.eventbus.Message.reply(Message.java:58)
        at org.vertx.java.busmods.BusModBase.sendStatus(BusModBase.java:60)
        at org.vertx.java.busmods.BusModBase.sendOK(BusModBase.java:64)
        at com.vcint.mdss.worker.EchoVerticle.access$0(EchoVerticle.java:1)
        at com.vcint.mdss.worker.EchoVerticle$1.handle(EchoVerticle.java:20)

(All my toy Verticle does at the moment is reply to the message with what was originally sent)

Does this mean that workers can't reply to or publish messages (!!!!!????????!???? - this can't be right!!!!)

I found some source code for a "memcache" BusMod and it says it should be run as a worker. That sends replies to messages, so I must be going insane...

I also read in the documentation that...

"Worker verticles are also not allowed to use TCP or HTTP clients or servers"

Have I misunderstood something?? (Most JDBC drivers are TCP clients...)

Any help would be appreciated...

(I sometimes think I should have listened to my father and become a plumber instead...)

Thanks,

- A confused Bret

[bac...@gmail.com]

More...

The above stack trace was the result of sending a reply. This stack trace occurs when I try and publish anything to the event bus from within a worker verticle...

Exception in Java verticle script
java.lang.IllegalStateException: Cannot be used in a worker application
        at org.vertx.java.core.net.impl.DefaultNetClient.<init>(DefaultNetClient.java:61)
        at org.vertx.java.core.impl.DefaultVertx.createNetClient(DefaultVertx.java:106)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendRemote(DefaultEventBus.java:494)

        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendToSubs(DefaultEventBus.java:340)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.access$300(DefaultEventBus.java:50)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus$2.handle(DefaultEventBus.java:374)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus$2.handle(DefaultEventBus.java:369)
        at org.vertx.java.core.eventbus.impl.hazelcast.HazelcastSubsMap$3.handle(HazelcastSubsMap.java:119)
        at org.vertx.java.core.eventbus.impl.hazelcast.HazelcastSubsMap$3.handle(HazelcastSubsMap.java:94)
        at org.vertx.java.core.impl.BlockingAction$1$1.run(BlockingAction.java:60)
        at org.vertx.java.core.impl.Context$2.run(Context.java:122)
        at org.vertx.java.core.impl.Context$1.run(Context.java:112)
        at org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:90)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)

Thanks

[Tim Fox]

On Thursday, 7 February 2013 14:10:43 UTC, bac...@gmail.com wrote:

Hi,

I'm trying to develop a worker Verticle that needs to do out-of-process calls.

When I run the Verticle, everything works fine.

However, when I add the "-worker" switch to tell VertX to run it as a worker, I don't seem to be able to reply to any messages or publish to the event bus from within the Verticle without getting the following exception...

Exception in Java verticle script
java.lang.IllegalStateException: Cannot be used in a worker application
        at org.vertx.java.core.net.impl.DefaultNetClient.<init>(DefaultNetClient.java:61)
        at org.vertx.java.core.impl.DefaultVertx.createNetClient(DefaultVertx.java:106)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendRemote(DefaultEventBus.java:494)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendOrPub(DefaultEventBus.java:363)
        at org.vertx.java.core.eventbus.impl.DefaultEventBus.sendReply(DefaultEventBus.java:295)
        at org.vertx.java.core.eventbus.impl.BaseMessage.reply(BaseMessage.java:53)
        at org.vertx.java.core.eventbus.Message.reply(Message.java:58)
        at org.vertx.java.busmods.BusModBase.sendStatus(BusModBase.java:60)
        at org.vertx.java.busmods.BusModBase.sendOK(BusModBase.java:64)
        at com.vcint.mdss.worker.EchoVerticle.access$0(EchoVerticle.java:1)
        at com.vcint.mdss.worker.EchoVerticle$1.handle(EchoVerticle.java:20)

(All my toy Verticle does at the moment is reply to the message with what was originally sent)

This is a known issue. It only occurs when you try to send the message to another node of the cluster. 

Does this mean that workers can't reply to or publish messages (!!!!!????????!???? - this can't be right!!!!)

Workaround is to proxy messages through a local non-worker verticle.

Will be fixed in Vert.x 2.0 

I found some source code for a "memcache" BusMod and it says it should be run as a worker. That sends replies to messages, so I must be going insane...

I also read in the documentation that...

"Worker verticles are also not allowed to use TCP or HTTP clients or servers"

Have I misunderstood something?? (Most JDBC drivers are TCP clients...)

It means _Vert.x_ TCP clients or servers.

[bac...@gmail.com]

Thanks for the quick response! You are a diamond!!

[bac...@gmail.com]

Hi,

I just thought I'd put a quick post here for anyone who might be interested in how to do this...

My toy application is currently very small, I have two java classes (one called "EchoVerticle" and one called "ProxyVerticle") - the app is just to help me get used to writing Worker verticles, so doesn't do anything interesting at the moment (it just echos any messages back to the sender)

The "EchoVerticle" is to be deployed as a worker and the "Proxy" as just a normal verticle.

I wrote a "DeployVerticle" to set these up...

public class DeployVerticle extends Verticle {

    @Override
    public void start() throws Exception {
        Handler<String> handler = new Handler<String>() {

            @Override
            public void handle(String event) {
            }
        };

        UUID uuid = UUID.randomUUID();

        JsonObject config = new JsonObject();

        config.putString("targetAddress", uuid.toString());

        System.out.println("Worker address: " + uuid);
        container.deployVerticle(ProxyVerticle.class.getName(), config, 1, handler);
        System.out.println("DEPLOYED FIRST");
        container.deployWorkerVerticle(EchoVerticle.class.getName(), config, 1, handler);
        System.out.println("DEPLOYED SECOND");
    }
}

What it is doing is generating a UUID that it passes in to the config of each of the other verticles.

The "EchoVerticle" will register a handler on this address (all it does is send the original message body as the reply)

The "ProxyVerticle" will register a handler on a "known" address (in this case, they always register a handler on an address named "proxy") and when it receives a message, it sends another message to the "UUID" address. When it gets a reply, it sends that reply back to the original sender.

The reason I am generating a UUID and using that is because I don't want a worker running on another JVM to pick up the message otherwise things will go bang. (There's probably a better way of doing this that I am unaware of... Did I read about "local verticles" somewhere, or did I just dream it...?)

I was getting NullPointerExceptions when programatically deploying. This was due to having a null deployment callback handler (see https://groups.google.com/forum/#!msg/vertx/a9jzAYINaEM/Dd4ce35DbIIJ) - hence the dummy handler.

Here's the rest of the code...

ProxyVerticle.java

public class ProxyVerticle extends Verticle {

    @Override
    public void start() throws Exception {
        System.out.println("START PROXY");
        final EventBus eventBus = vertx.eventBus();

        eventBus.registerHandler("proxy", new Handler<Message<JsonObject>>() {

            @Override
            public void handle(final Message<JsonObject> event) {
                System.out.println("PROXY: Got a message " + event.body);
                eventBus.send(getContainer().getConfig().getString("targetAddress"), event.body, new Handler<Message<JsonObject>>() {

                    @Override
                    public void handle(Message<JsonObject> reply) {
                        System.out.println("PROXY: SEND REPLY");
                        event.reply(reply.body);
                    }
                });
            }
        });
    }

}

EchoVerticle.java

public class EchoVerticle extends Verticle {

    @Override
    public void start() {
        System.out.println("DEPLOYING ECHO");
        vertx.eventBus().registerHandler(getContainer().getConfig().getString("targetAddress"), new Handler<Message<JsonObject>>() {

            @Override
            public void handle(Message<JsonObject> event) {
                System.out.println("GOT " + event.body + ", SENDING REPLY");
                event.reply(event.body);
            }

        }, new AsyncResultHandler<Void>() {

            @Override
            public void handle(AsyncResult<Void> event) {
                System.out.println("REGISTERED!!");
            }
        });
    }

}

Looking forward to VertX 2.0!!

[Tim Fox]

I'm pretty sure that was fixed in 1.3.1 - If not please re-open the issue

--
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/groups/opt_out.
 
 

[bac...@gmail.com]

You're right...

Just realized I am running 1.3.0, will upgrade now!!

Thanks Tim

[Tim Fox]

Np!

[Alexander Eder]

Hi,

I'm getting the exception even in 1.3.1. I'm using a cluster setup. One machine for the verticle and another for the workers. When I'm deploying everything in one machine everything works as intended.  

this is my deploy code. I'm starting one server with 0 worker instances and 4 http instances and another with 0 http and 4 workers.

One one maschine with 4 http and 4 workers this works.

container.deployWorkerVerticle("de.isogmbh.ad.verticle.DatabaseWorker", new JsonObject(), config.getInteger("vertx.worker.instances"), new Handler<String>() {

@Override

public void handle(String arg0) {

container.getLogger().info("Database Worker Deployed");

container.getLogger().info("Deploy finished");

}

});

container.deployVerticle("de.isogmbh.ad.verticle.HttpServer", new JsonObject(), config.getInteger("vertx.http.instances"), new Handler<String>() {

@Override

public void handle(String arg0) {

container.getLogger().info("Http Server Deployed");

}

});

[Tim Fox]

Can you please open a github issue with stack trace etc?

[Tim Fox]

When I said this was fixed in 1.3.1 I was referring to the exception the user had reported, not the one you just posted an issue about!

On Wednesday, 13 February 2013 10:53:51 UTC, Alexander Eder wrote:

[Alexander Eder]

using the proxy workaround for now.