Differences

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

Link to this comparison view

irc:1486508400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:03:36] <​temporalfox>​ what are you working on at the moment ?
 +
 +[00:06:15] <​wsiqueir>​ BRMS/BPM Suite and RESTeasy
 +
 +[00:07:17] <​wsiqueir>​ but I like rest in general - I was writing a vert.x tutorial for my blogs, so I entered this channel - but we have a vert.x expert in ur JUG already and he gave talks about vert.x
 +
 +[00:07:58] <​temporalfox>​ wsiqueir cool
 +
 +[00:08:05] <​temporalfox>​ is the expert in the ocmmunity ?
 +
 +[00:15:17] <​wsiqueir>​ Yes, I think he works with vert.x when doing freelance work
 +
 +[00:15:37] <​wsiqueir>​ temporalfox,​ thanks for all the great contributions :)
 +
 +[01:17:45] *** ChanServ sets mode: +o temporalfox
 +
 +[01:32:43] *** ChanServ sets mode: +o temporalfox
 +
 +[02:18:58] *** ChanServ sets mode: +o temporalfox
 +
 +[07:38:57] <​wsieroci>​ is it possible to somehow restart verticle in case of uncaught exception?
 +
 +[09:47:03] <​temporalfox>​ ppatiern hi, I've seen you are doing progress on kafka
 +
 +[09:47:33] <​ppatiern>​ temporalfox:​ yes ! I'm jumping between different stuff ... Hono, EnMasse and Kafka :-)
 +
 +[09:47:53] <​temporalfox>​ can we have something reviewed this week ?
 +
 +[09:48:56] <​ppatiern>​ I will try to add more examples I can
 +
 +[10:16:14] <​ploffay>​ Hey, is it possible to have multiple
 +
 +[10:16:29] <​ploffay>​ Hey, is it possible to call multiple `routingContext.addBodyEndHandler` for one request?
 +
 +[10:16:56] <​ploffay>​ e.g request matches multiple handlers and all of them defines boduEndHandler
 +
 +[10:17:22] <​ploffay>​ in my case one one is called
 +
 +[10:20:39] <​myghty>​ hey
 +
 +[10:20:42] <​myghty>​ !
 +
 +[10:21:01] <​myghty>​ just a question... I wanna use an external hazelcast cluster for my autodiscovery and stuff
 +
 +[10:21:18] <​myghty>​ found in the documentation,​ that I can just hand over a manually created hazelcast client-instance to do that
 +
 +[10:22:43] <​myghty>​ but for unit tests I would just like to startup the verticle as usual like starting it with --clustered
 +
 +[10:23:26] <​myghty>​ so using the internal hazelcast... (I wanna test if I can add a SpringBoot microservice to the vertx discovery and therefore would like to test that via hazelcast)
 +
 +[10:23:44] <​myghty>​ but how do I boot up the verticle programmatically and initiate the internal hazelcast?
 +
 +[10:24:02] <​myghty>​ I know how to use .deploy but I do not see an option to start the hazelcast internally as well
 +
 +[11:20:58] <​ploffay>​ solved, my fault...
 +
 +[14:32:54] <​ppatiern>​ temporalfox:​ ping
 +
 +[14:33:27] <​temporalfox>​ ppatiern hi
 +
 +[14:33:42] <​ppatiern>​ a question while writing examples and doc for Kafka client ...
 +
 +[14:34:24] <​temporalfox>​ yes
 +
 +[14:34:25] <​ppatiern>​ we know that the client has two types of APIs ... both are streams but one of them is polyglot and the other one isn't and it uses Kafka native objects
 +
 +[14:34:57] <​ppatiern>​ the polyglot version relies on the non-polyglot one
 +
 +[14:34:58] <​temporalfox>​ there is an annotation
 +
 +[14:35:19] <​temporalfox>​ @Source(translate = false)
 +
 +[14:35:31] <​temporalfox>​ and you package the examples in different examples
 +
 +[14:35:58] <​ppatiern>​ but my question is ... should we have to document both ?
 +
 +[14:36:25] <​ppatiern>​ they look the same from an API point of view
 +
 +[14:36:43] <​ppatiern>​ quite same methods .. and the polyglot version calls the non-polyglot
 +
 +[14:37:01] <​temporalfox>​ I think you should document the polyglot
 +
 +[14:37:02] <​temporalfox>​ and after
 +
 +[14:37:11] <​temporalfox>​ you make a small chapter about non polyglot
 +
 +[14:37:25] <​temporalfox>​ and show a few example
 +
 +[14:37:29] <​temporalfox>​ and say it uses kafka nativeobjects
 +
 +[14:37:34] <​ppatiern>​ make sense ... agree
 +
 +[14:37:52] <​ppatiern>​ thanks ;)
 +
 +[14:37:53] <​temporalfox>​ maybe we can have a common interface between them
 +
 +[14:37:59] <​temporalfox>​ using covariance
 +
 +[14:38:18] <​temporalfox>​ but that would remain complicated
 +
 +[14:38:47] <​ppatiern>​ let's go ahead in this way for now ... just for the first release
 +
 +[14:42:13] <​myghty>​ temporalfox:​ any idea on my question? :)
 +
 +[14:42:30] <​temporalfox>​ myghty let me read it
 +
 +[14:42:55] <​temporalfox>​ I think we do have some examples in the HZ tests
 +
 +[14:43:19] <​myghty>​ ah :)
 +
 +[14:43:24] <​myghty>​ good idea to look at that
 +
 +[14:43:29] <​temporalfox>​ create VertxOptions
 +
 +[14:43:33] <​myghty>​ I am not used to projects having unit tests ;D
 +
 +[14:43:35] <​temporalfox>​ call setClusterManager(new HazelcastClusterManager())
 +
 +[14:43:40] <​temporalfox>​ on it
 +
 +[14:43:53] <​temporalfox>​ and then start your vertx with clusteredVertx(options,​ ar -> {})
 +
 +[14:43:55] <​myghty>​ ah okay and then it will start up the hazelcast internally :)
 +
 +[14:43:57] <​myghty>​ cool
 +
 +[14:44:01] <​myghty>​ thanks :)
 +
 +[14:44:44] <​myghty>​ btw, if I wanna use the service discovery from something like spring boot, it is just writing my service record to the service.registry map, right?
 +
 +[14:44:49] <​myghty>​ or did I miss something?
 +
 +[14:55:36] <​temporalfox>​ I think yes
 +
 +[14:55:41] <​temporalfox>​ I'm not that much familliar with it
 +
 +[14:55:42] <​myghty>​ awesome :) thanks
 +
 +[14:55:44] <​myghty>​ hehe
 +
 +[14:55:50] <​temporalfox>​ don't hesiate to post on vertx groups :-)
 +
 +[14:55:54] <​myghty>​ I finally need time to finish my blogposts about vertx... :)
 +
 +[14:56:14] <​myghty>​ I have like 4-5 interesting things in the pipeline but thanks to work I do not get to a point where I could finish them -.-
 +
 +[15:05:02] <​temporalfox>​ have you tried 3.4.0.Beta1 ?
 +
 +[15:05:22] <​myghty>​ not yet :)
 +
 +[15:06:04] <​myghty>​ working here in a high secure environment... it was hard enough to get vert.x approved at all :D
 +
 +[16:17:50] <​temporalfox>​ I see
 +
 +[18:56:19] <​ploffay>​ Hey, is there a way to intercept all incoming messages from the bus?
 +
 +[20:13:34] <​temporalfox>​ no
 +
 +[20:13:41] <​temporalfox>​ well yes actually
 +
 +[20:13:49] <​temporalfox>​ using metrics
 +
 +[20:13:52] <​temporalfox>​ you can provide your own metrics implementation that does that
 +
 +[20:14:02] <​temporalfox>​ we do have a receive bus interceptor work planned also
 +
 +[21:13:17] *** ChanServ sets mode: +o temporal_