Differences

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

Link to this comparison view

irc:1494972000 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[08:24:27] <​temporalfox>​ ppatiern hi
 +
 +[09:18:57] <​ppatiern>​ temporalfox:​ hi
 +
 +[09:19:02] <​temporalfox>​ hi
 +
 +[09:19:53] <​temporalfox>​ I would like to have the PR in vertx-kafka-client to be merged
 +
 +[09:19:59] <​temporalfox>​ can you take care of that this week ?
 +
 +[09:20:05] <​ppatiern>​ I'm working on that now :-)
 +
 +[09:20:26] <​ppatiern>​ for sure this morning it will be merged or I'll ask for changes
 +
 +[09:21:06] <​ppatiern>​ Tom is working on the AMQP Kafka bridge with me and we are integrating the Kafka client into that ... so it will be 100% "​Vert.x-ed"​ :-)
 +
 +[09:21:43] <​temporalfox>​ great
 +
 +[09:22:23] <​ppatiern>​ fyi .. I used it in my demo at summit mentioning that it's developed using Vert.x ;)
 +
 +[09:23:45] <​temporalfox>​ that's great to hear that
 +
 +[09:23:49] <​temporalfox>​ is the video on youtube ?
 +
 +[09:24:11] <​ppatiern>​ It was in a room with no recording :-(
 +
 +[09:24:40] <​ppatiern>​ Btw they asked me to record a video of my part of the session (about the bridge) ... I'll do that asap
 +
 +[09:29:42] <​temporalfox>​ ok
 +
 +[09:29:44] <​temporalfox>​ good to know
 +
 +[09:29:53] <​temporalfox>​ don't forget to ask to add on the "​vertx"​ youtube channel
 +
 +[09:33:28] <​ppatiern>​ ok !
 +
 +[09:36:57] <​temporalfox>​ any conf expected soon ?
 +
 +[09:37:17] <​temporalfox>​ next year submit to rivieradev if there is a judcon track again
 +
 +[09:37:33] <​ppatiern>​ yes sure !
 +
 +[09:38:00] <​ppatiern>​ in the coming weeks May 22nd and June 5th I'll have a couple of sessions about EnMasse in Italy (Naples and Milan)
 +
 +[09:38:27] <​ppatiern>​ not speaking about Vert.x ... but it's always mentioned because a lot of EnMasse components use it
 +
 +[09:50:15] <​temporalfox>​ ok
 +
 +[09:50:38] <​temporalfox>​ so you're going to meet Francesco in Milan ?
 +
 +[10:10:55] <​ppatiern>​ it's possible. I don't know if he will join the meetup.
 +
 +[10:11:53] *** ChanServ sets mode: +o purplefox
 +
 +[10:55:22] *** ChanServ sets mode: +o purplefox
 +
 +[11:53:10] *** ChanServ sets mode: +o purplefox
 +
 +[16:33:10] <​yarekt>​ Hi, verticles. Got a question about running a forever loop in a verticle, Fine to do it in start() ? In that case deploy handler never gets called :(
 +
 +[16:33:26] <​yarekt>​ I heard somewhere step() mentioned, but can't find it
 +
 +[16:33:41] <​yarekt>​ I'm using vertx core 3.3.3
 +
 +[16:35:06] <​tsegismont>​ yarekt, hi, not sure what you mean whith forever loop, but you should definitely not prevent the start method to complete, otherwise your event loop is blocked and nothing will happen
 +
 +[16:35:43] <​tsegismont>​ yarekt, if you just want to execute something periodically then vertx.setPeriodic will do
 +
 +[16:36:33] <​yarekt>​ I'm using a Worker verticle option, which doesn'​t block the event loop. Will periodic execution be the same as sort of speed as an infinite loop? I'm essentially reading data and sending to event Bus
 +
 +[16:36:39] <​yarekt>​ (reading/​generating)
 +
 +[16:37:52] <​yarekt>​ Is periodic delay of 0L alright ?
 +
 +[16:39:17] <​yarekt>​ Vertx says no: "​Cannot schedule a timer with delay < 1 ms"
 +
 +[16:40:04] <​yarekt>​ tsegismont: Usecase is for example I want to send generated messages as fast as possible from a verticle
 +
 +[16:42:23] <​tsegismont>​ yarekt, a worker verticle does not mean you can block the worker thread indefinetly
 +
 +[16:44:03] <​tsegismont>​ yarekt, because two events cannot be handled at the same in parallel
 +
 +[16:44:51] <​tsegismont>​ yarekt, you're reading data from what, a file ?
 +
 +[16:46:24] <​yarekt>​ I'm reading from a polling queue
 +
 +[16:46:55] <​tsegismont>​ what kind of queue ?
 +
 +[16:47:09] <​yarekt>​ A queue that I have to poll to get a batch of messages
 +
 +[16:47:23] <​yarekt>​ List<​Message>​ batch = queue.getBatch()
 +
 +[16:48:23] <​yarekt>​ But an example of data generator works well here, publisher.send(i++);​ something like that
 +
 +[16:50:25] <​tsegismont>​ so queue.getBatch is blocking I guess?
 +
 +[16:50:41] <​tsegismont>​ until there'​s a full batch or a timeout occurs?
 +
 +[16:50:46] <​yarekt>​ Yes, it blocks, but sometimes can return an empty list
 +
 +[16:51:28] <​tsegismont>​ Are you working with the Vert.x Java API, or an alt lang ?
 +
 +[16:51:39] <​yarekt>​ Java API
 +
 +[16:54:20] <​tsegismont>​ Then what I would do is the following:
 +
 +[16:55:36] <​tsegismont>​ Start your own thread, just for polling this queue
 +
 +[16:55:42] <​tsegismont>​ and publish to the event bus
 +
 +[16:56:29] <​tsegismont>​ you can call vertx.eventBus().send or publish from any thread
 +
 +[16:56:43] <​yarekt>​ And shut the thread down in stop() ?
 +
 +[16:57:01] <​tsegismont>​ and then in a verticle register the event bus handlers
 +
 +[16:57:17] <​tsegismont>​ well, it depends :)
 +
 +[16:57:27] <​tsegismont>​ How do you start your app ? With your own main ?
 +
 +[16:57:48] <​yarekt>​ Yea, I suppose it will never really be shut down really :)
 +
 +[16:58:58] <​tsegismont>​ you can start/stop the thread from the start/stop methods
 +
 +[16:59:35] <​tsegismont>​ just make sure it's fine if you create multiple instances of the verticle
 +
 +[17:00:35] <​yarekt>​ Hmm, Its fine, it just means there will be dulplicate messages on the bus, but as long as they are all in strict order it shouldn'​t matter. Why would there be more than one of these verticles?
 +
 +[17:03:10] <​tsegismont>​ http://​vertx.io/​docs/​vertx-core/​java/#​_specifying_number_of_verticle_instances
 +
 +[17:04:15] <​yarekt>​ Cool, That should work. Thanks for your help tsegismont :)
 +
 +[17:30:40] <​tsegismont>​ you're welcome
 +
 +[17:33:11] *** ChanServ sets mode: +o purplefox