[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? http://vertx.io/docs/vertx-rx/js/
[01:13:34] <npskirk> similar to node.js apps, except running in vertx on a JVM
[01:17:06] <npskirk> littleli but there is https://github.com/Reactive-Extensions/RxJS 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 http://vertx.io/docs/vertx-core/java/
[11:49:43] <vertxnewbie> I went through it, but doesn't really point out the relation or the gory details
[11:49:49] <purplefox> http://vertx.io/docs/vertx-core/java/#_reactor_and_multi_reactor
[11:50:15] <purplefox> http://vertx.io/docs/vertx-core/java/#_verticles
[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> http://vertx.io/docs/vertx-core/java/#_specifying_number_of_verticle_instances
[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 :)