This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[00:46:02] <AlexLehm> littleli: i don't think you can use vertx in the browser since it requires a jvm, you can only use the sockjs connection

[00:53:01] <littleli> AlexLehm: I'm confused, what does this documentation refers to then?

[01:12:36] <npskirk> littleli vertx is polyglot on the server side. That doc refers to things running on the server that happen to be written in javascript

[01:13:34] <npskirk> similar to node.js apps, except running in vertx on a JVM

[01:17:06] <npskirk> littleli but there is if you want to do reactive programing in the browser.

[01:19:02] <littleli> so if I understand it correctly, the client portion of that npm should be used from something like `jjs` and it's ment to be used on the server-side?

[01:24:41] <littleli> I'll stick to SockJS and write RxJS adapter if needed

[08:53:04] *** ChanServ sets mode: +o purplefox

[10:48:50] <vertxnewbie> HI…. what are multi threaded worker verticles ?

[11:00:39] <cescoffier> vertxnewbie: they are worker verticle than do not constraint the thread accessing it

[11:00:55] <cescoffier> vertxnewbie : so several threads can execute the verticle code at the same time

[11:01:05] <cescoffier> vertxnewbie : you should never use them :-)

[11:02:50] <vertxnewbie> But.. umm..

[11:03:16] <vertxnewbie> if the worker verticle is stateless, then would it be fine ?

[11:09:55] <vertxnewbie> cescoffier: If worker verticles are stateless, would it be fine to use them ?

[11:41:38] <vertxnewbie> Hi… sorry for troubling y'all ..

[11:42:06] <vertxnewbie> But if a worker verticle is stateless, is it fine to use it as a multi threaded worker verticle ?

[11:46:15] <purplefox> vertxnewbie: why not just use a normal verticle? MT workers are intended for advanced use cases, we don't recommend using them unless you have a very good reason to

[11:46:49] <vertxnewbie> I'm just trying to understand the ecosystem :) No real use case yet

[11:47:20] <purplefox> in which case i would pretend MT worker verticles don't exist right now :)

[11:47:37] <vertxnewbie> Hehe ok… Also could you point me to some documentation if possible that explains the relation between the event loop and a verticle ?

[11:47:49] <purplefox> ideally you don't want to use worker verticles at all. standard verticles are preferable

[11:48:22] <vertxnewbie> they are indeed.. but I have a few long tasks , report generation and such

[11:49:11] <purplefox> the main java manual is probably a good place to start

[11:49:43] <vertxnewbie> I went through it, but doesn't really point out the relation or the gory details

[11:49:49] <purplefox>

[11:50:15] <purplefox>

[11:50:34] <vertxnewbie> Thanks. I'll try reading them again, in case I missed something.

[11:50:48] <vertxnewbie> is there just 1 event loop thread per JVM instance ?

[11:51:06] <purplefox> nope, read the section on “multi-reactor” ;)

[11:51:16] <purplefox> (the multi means there are multiple event loops)

[11:51:25] <purplefox> that's what makes it different from just reactor

[11:51:43] <vertxnewbie> Ah .. you are correct

[11:52:12] <purplefox> this is one thing different from node.js and vert.x

[11:52:22] <purplefox> in node.js process there is always a single event loop, so it can use at most one core

[11:52:38] <vertxnewbie> Um hmm

[11:52:39] <vertxnewbie> How many instances of a “verticle” class are created ?

[11:52:40] <purplefox> so to scale a node.js app on your multi core server you must deploy many processes

[11:52:50] <purplefox> but with vert.x you can do all of that in a single process

[11:53:01] <purplefox> you create as many instances as you want

[11:53:11] <purplefox> of a verticle

[11:53:25] <purplefox> the number of instances is a parameter you supply when you deploy verticles

[11:53:51] <vertxnewbie> I guess I'll maintain shared state across the instances in some static variable.

[11:54:22] <purplefox>

[11:54:35] <vertxnewbie> Sorry if these sound very basic, I come from a spring ecosystem.. there is just the one instance there. :)

[11:54:53] <purplefox> vertxnewbie: you could use statics but i wouldn't recommend it, as that will open you up to race conditions

[11:55:15] <vertxnewbie> Yes.. but it is sort of necessary for my use case.

[11:55:21] <purplefox> vert.x provides you with something called SharedData which allows you to share stuff between verticle instances

[11:55:26] <vertxnewbie> I want to throttle API calls per instance

[11:55:36] <vertxnewbie> Ah.. that would be useful

[11:57:33] <vertxnewbie> I guess I don't really understand what the event loop threads do. Do they maintain the callback queue on their stack ? In that case, are all instances of a particular verticle bound to a single event loop thread ?

[11:57:46] <purplefox> an eventloop is just a thread

[11:58:13] <purplefox> it spins around delivering events to different handlers

[11:58:27] <purplefox> and it should never be blocked

[11:58:54] <purplefox> a particular standard verticle instance is always serviced by the same event loop

[11:59:16] <purplefox> that means you don't have to worry about race conditions as you know your code is only ever touched by the same thread

[12:01:02] <purplefox> different verticle instances can be bound to different event loops

[12:03:16] <vertxnewbie_> sorry… disconnected

[12:05:41] <vertxnewbie> purplefox: could you resend your last message about the eventloop ?

[12:09:08] <vertxnewbie> sorry for the trouble

[12:10:53] <vertxnewbie> Anyway… I'll go through the source code.. Thanks for all the help :)

[12:12:47] <purplefox> vertxnewbie: what's the last message you saw?

[12:13:16] <vertxnewbie> I went through the logs :)

[12:13:26] <purplefox> ah ok :)