Work queue module and Vert.x 3.0

590 views
Skip to first unread message

Daniel Feist

unread,
Jul 16, 2015, 9:50:11 AM7/16/15
to ve...@googlegroups.com
Hi,

Just wondering if the "work queue" module still applies to Vert.X 3.0, and just needs updating, or if Vert.X 3 takes a different approach to this..

thank!

Dan

bytor99999

unread,
Jul 16, 2015, 12:48:40 PM7/16/15
to ve...@googlegroups.com
You can't use Vert.x 2.x modules with Vert.x 3. Vert.x 3 doesn't have modules anymore. ;) and no more deployModule() methods

Mark

Daniel Feist

unread,
Jul 16, 2015, 1:47:21 PM7/16/15
to ve...@googlegroups.com
I understand that.  The question was more around how you'd do what the work queue module does with Vert.x 3.. 

Dan

Tim Fox

unread,
Jul 16, 2015, 1:49:45 PM7/16/15
to ve...@googlegroups.com
On 16/07/15 18:47, Daniel Feist wrote:
I understand that.  The question was more around how you'd do what the work queue module does with Vert.x 3..

In pretty much the same way I guess :)

The work queue primarily uses verticles and the event bus which both work in pretty much the same way in V3.


Dan


On Thursday, July 16, 2015 at 5:48:40 PM UTC+1, bytor99999 wrote:
You can't use Vert.x 2.x modules with Vert.x 3. Vert.x 3 doesn't have modules anymore. ;) and no more deployModule() methods

Mark

On Thursday, July 16, 2015 at 6:50:11 AM UTC-7, Daniel Feist wrote:
Hi,

Just wondering if the "work queue" module still applies to Vert.X 3.0, and just needs updating, or if Vert.X 3 takes a different approach to this..

thank!

Dan
--
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.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7caf2fc0-8cae-47e1-9c42-b80de5b94314%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Feist

unread,
Jul 17, 2015, 8:21:50 AM7/17/15
to ve...@googlegroups.com
Ok, but work queue still hasn't been upgraded for 3.x right.  Correct?

In the mean time is there anyway to do this kind of things and get expected 20TPS and not 1 TPS (with default worker pool size of 20)


    Vertx vertx = Vertx.vertx();
vertx.deployVerticle(new AbstractVerticle()
{
@Override
public void start() throws Exception
{
vertx.setPeriodic(50, event -> vertx.eventBus().send("foo", "HELLO"));
}
});
vertx.deployVerticle(new AbstractVerticle()
{
@Override
public void start() throws Exception
{
vertx.eventBus().consumer("foo", event -> {
try
{
System.out.println("IN " + Thread.currentThread().getName());
Thread.sleep(1000);
System.out.println("OUT " + Thread.currentThread().getName());
}
catch (InterruptedException e)
{
e.printStackTrace();
}
});
}
}, new DeploymentOptions().setWorker(true).setMultiThreaded(true));

Dan

Tim Fox

unread,
Jul 17, 2015, 8:52:02 AM7/17/15
to ve...@googlegroups.com
I wouldn't recommend multi-threaded workers unless you have a very good reason for using them.

Have you tried standard worker and deploying 20 instances?

Daniel Feist

unread,
Jul 17, 2015, 9:45:02 AM7/17/15
to ve...@googlegroups.com
Hi Tim,

Not sure how to configure 20 instances..

Exception in thread "main" java.lang.IllegalArgumentException: Can't specify > 1 instances for already created verticle
at io.vertx.core.impl.DeploymentManager.deployVerticle(DeploymentManager.java:70)
at io.vertx.core.impl.VertxImpl.deployVerticle(VertxImpl.java:516)

Anyway, unless there is some way to decouple reading from the eventbus and blocking processing, won't the eventbus.send() be blocked for 1 second.  I'm assuming eventbus operates like a SyncQueue and doesn't have a in-built buffer.  I couldn't try it anyway, because Vert.x wouldn't let me deploy 20 instances, see error above.

Dan

Tim Fox

unread,
Jul 17, 2015, 10:23:18 AM7/17/15
to ve...@googlegroups.com
On 17/07/15 14:45, Daniel Feist wrote:
Hi Tim,

Not sure how to configure 20 instances..

bytor99999

unread,
Jul 17, 2015, 12:39:21 PM7/17/15
to ve...@googlegroups.com


On Friday, July 17, 2015 at 5:52:02 AM UTC-7, Tim Fox wrote:
I wouldn't recommend multi-threaded workers unless you have a very good reason for using them.

Have you tried standard worker and deploying 20 instances?

So I am curious as to why? For us, we have found no difference in code running successfully and on performance. They both acted identical. So we actually only deploy one multi-threaded worker per each worker verticle we have. Now, if the Verticle is say an Actor like Verticle where there is say a Verticle per player then I might see why. No, actually I still don't as a multi-threaded worker will still just use a thread from the thread pool if there is more than one thread calling that Verticle simultaneously. So I am still confused and really would love to know the real difference.

Thanks for your help

Mark
Reply all
Reply to author
Forward
0 new messages