Differences

This shows you the differences between two versions of the page.

Link to this comparison view

— irc:1452898800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[05:30:51] *** ChanServ sets mode: +o temporalfox
 +
 +[10:35:43] <drfits> Hi there
 +
 +[10:36:16] <drfits> I need a vertx-jdbc-client-3.2.0.jar as bundle - where I can find it?
 +
 +[10:36:35] <drfits> because now I'm creating it by hands
 +
 +[10:37:08] <drfits> and this is a frustrated
 +
 +[12:11:26] <temporalfox> drfits you mean osgi bundle ?
 +
 +[14:30:26] <ajin> Hi
 +
 +[14:33:59] <ajin> In vertx we are not suppose to have more than one instance of a verticle running concurrently right? But is this limited to a vertx instance (Java process), that is I can run multiple instance of same verticle in multiple servers in the cluster concurrently, or is it limited to the entire cluster, that is in one event bus cluster, there can be only one instance of a given verticle. Any pointers to relevant documentation will be helpful
 +
 +[14:39:43] <AlexLehm> you can deploy a verticle more than once even in the local jvm
 +
 +[14:41:48] <ajin> @AlexLehm you mean I can have two jvm instance running vertx and both can have same verticle running concurrently right?
 +
 +[14:42:00] <AlexLehm> yes
 +
 +[14:42:17] <AlexLehm> the communication will happen via the event bus, so it doesn't really matter which verticle it is
 +
 +[14:43:59] <ajin> Thanks, but one more thing. I read somewhere that each verticle is totally isolated, even have separate class loaders, is that the case within a single jvm instance running multiple verticle?
 +
 +[14:44:30] <AlexLehm> i think that was the case in vert.x 2.x, in vert.x 3.x the is a normal class loader I think
 +
 +[14:44:53] <AlexLehm> the class stuff got much simpler in vertx. 3
 +
 +[14:47:50] <ajin> Just curious about one more thing, Can we have a cluster with both vert.x 2 and 3?
 +
 +[14:48:17] <ajin> This way migration will be easier.
 +
 +[15:04:59] <AlexLehm> i think that will not work, but i am not sure
 +
 +[15:05:31] <AlexLehm> the cluster software is a different version i think
 +
 +[15:11:28] <ajin> Thank you once again.
 +
 +[15:11:42] <ajin> Have a good day.
 +
 +[15:17:40] *** ChanServ sets mode: +o temporalfox
 +
 +[15:28:36] *** ChanServ sets mode: +o temporalfox
 +
 +[16:45:34] <drfits> temporalfox: yes, I've added PR for this, but now I'm wondering where I should update documentation for this
 +
 +[16:45:58] <drfits> regarded to https://github.com/vert-x3/vertx-jdbc-client/pull/39
 +
 +[16:46:04] <temporalfox> I believe that Cl[unknown:eacute]ment will ahve a look, he is our osgi specialist
 +
 +[16:46:15] <temporalfox> you can reach the google group too, you will surely get an answer
 +
 +[16:47:39] <drfits> thank you, but I haven't question for G group right now, only how I could update documentation :)
 +
 +[18:35:11] <ajin> Hi, I went through vert.x web documentation, Here is one thing I can't figure out how to do. Lets say I have two APIs, /api/student and /api/teacher. I want all the requests to student API to be handled by one verticle and teacher API by another. Just like two Spring controllers would be. How to do this, or is this the right approach?
 +
 +[18:43:01] <ajin> I think I figured it out. I'm not supposed to create multiple verticles for handling different APIs, I should create multiple handlers and register them instead.
 +
 +[18:43:17] <ajin> Please correct me if I'm wrong.
 +
 +[19:04:56] <drfits> ajin: from my point you are right
 +
 +[19:50:02] <theRealGent> Hello. Is there any benefit of using vertx's redis client as opposed to some defacto popular library?
 +
 +[20:10:35] <drfits> theRealGent: I believe it depends on implementation and application infrastructure :)
 +
 +[20:19:29] <theRealGent> Is there a way to have an init class find all the verticles on the classpath and deploy them automatically for you?
 +
 +[20:19:40] <theRealGent> (Embedded vertx with shaded jar)
 +
 +[20:42:48] <theRealGent> And why would a verticle create its own http server? I see this a lot in the examples. Wouldn't an http server be shared across verticles? And I can have different verticles corresponding to different api endpoints as an example?
 +
 +[20:44:21] <temporalfox> theRealGent the benefit of vertx redis client is to be integrated with the non blocking model of vertx
 +
 +[21:27:50] <drfits> some month ago I saw in NodeJS article that for PayPal was implemented functionality where if execution of request will take more than 5 seconds all new requests will be rejected. So is it possible to create for Vert.x this functionality?
 +
 +[21:28:58] <theRealGent> so if the event loop is critical to not block, using a synchronous logging framework would be bad right?
 +
 +[21:29:22] <theRealGent> If disk IO got crazy, I would be slowing my application down right?
 +
 +[21:29:38] <theRealGent> Is the built in logging framework in Vert.x nonblocking?
 +
 +[21:30:42] <drfits> theRealGent - your application writing so much logs?
 +
 +[21:30:57] <theRealGent> drfits, no
 +
 +[21:32:41] <drfits> in any case you could always create blocking pool for logging
 +
 +[21:33:19] <drfits> or using some cloud log service, or create custom logging system
 +
 +[21:35:20] <drfits> for me the most hard thing to convince other developers that proxy implementation should be on vert.x instead of servlets
 +
 +[22:01:50] <SmilSENIL> N00b question, here goes: I can't really grasp the Polyglot part of Vertx. Can I write a vertx client in JavaScript with the same functionality as if I wrote it in Java or another JVM language?
 +
 +[22:02:51] <SmilSENIL> Or is the JavaScript vertx API a sort of wrapper around AMQP, which in turn speaks to the vertx Event Bus?
 +
 +[22:15:42] <temporalfox> SmilSENIL yes the polyglot allows to use the same api in Java or JavaScript
 +
 +[22:16:06] <temporalfox> it is javascript running inside the Java Virtual Machine with the Nashorn engine
 +
 +[22:40:30] <SmilSENIL> temporalfox: That explains a lot. So any language you would like to write a vertical in would need to be runnable within the JVM, right? So Ruby is really JRuby?
 +
 +[22:40:41] <temporalfox> yes
 +
 +[22:40:43] <temporalfox> correct
 +
 +[22:41:01] <temporalfox> that being said it is possible to send message to vertx event bus using websocket or TCP
 +
 +[22:41:07] <SmilSENIL> Ah, ok thanks!
 +
 +[22:41:14] <temporalfox> and we do provide a JavaScript client for Node / Browser
 +
 +[22:42:31] <SmilSENIL> And also, there is a generic AQMP interface that would make it possible to use vertx from a non-JVM language, similar to using an external RabbitMQ or another AMQP-compatible server?
 +
 +[22:44:08] <temporalfox> yes indeed but that is not yet in the vertx stack
 +
 +[22:45:51] <SmilSENIL> thanks. What about the Node/Browser client. Do I have access to the full API in those? Can I write a vertical using those? Or is a Vertical, by definition, something that is running within the JVM?
 +
 +[22:47:08] <temporalfox> verticle is running inside the JVM
 +
 +[22:47:16] <temporalfox> so it is exclusive to JVM
 +
 +[22:47:40] <temporalfox> you should consider using the JS lang of Vert.x, if you are doing node, it should be natural to you
 +
 +[22:48:59] <SmilSENIL> The "JS lang of Vert.x", is that Nashorn engine JS?
 +
 +[22:51:25] <temporalfox> yes
 +
 +[22:56:26] <SmilSENIL> Great. What about the Node/Browser client, is that mainly a client that can send and receive message to the Vert.x event bus? The rest of the code is written "as you normally would" in Node/Browser?
 +
 +[22:57:11] <temporalfox> you are correct, it provides a similar eventbus api than the one with Nashorn
 +
 +[22:57:21] <temporalfox> and the rest is up to you
 +
 +[22:59:26] <SmilSENIL> Thanks, this is great info. I'm considering using Vert.x for a very large customer project. I really like the idea of kind of "internalizing" the event bus into the Vert.x platform, instead of having a completely separate MQ. like RabbitMQ or Kafka.
 +
 +[22:59:57] <temporalfox> as the doc says, the eventbus is the nervous system of vert.x
 +
 +[23:01:53] <SmilSENIL> Is it correct that one Vertical == one service, but they are still deployed in the same JVM, or rather in the same JVM cluster? Can Verticals be deployed separately even though they are executed in the same JVM?
 +
 +[23:03:51] <temporalfox> usually a verticle is indeed one service (but it does not have to be)
 +
 +[23:03:57] <temporalfox> then you can deploy them in the same JVM
 +
 +[23:03:59] <temporalfox> or not
 +
 +[23:04:14] <temporalfox> if they communicate via eventbus, it will be the same
 +
 +[23:07:44] <SmilSENIL> I'm thinking of the unit of deployment. Can I have different Verticals, written in different languages, saved in different repos, but still deployed to the same Vert.x cluster? Or would I need to have them all as subprojects to be able to build them all in the same fat-jar?