










[07:05:16] <cescoffier> purplefox: can you create two repositories on github: vertx-openshift-diy-quickstart and vert-openshift-cartridge ?
[10:20:23] <spriet2000> Alex, last week we were talking about a finishing a list of futures async[unknown:hellip] i found out concurency lib has something for the problem its called CompletionService
[10:20:46] <spriet2000> http://blog.teamlazerbeez.com/2009/04/29/java-completionservice/
[10:21:17] <spriet2000> i think its working with threads but for the idea
[10:21:41] <spriet2000> http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CompletionService.html
[10:24:25] <spriet2000> oef alex isnt here :>
[10:28:45] <spriet2000> question, is there a completionservice in vertx ? using the eventloop and async?
[10:29:28] <spriet2000> or are different patterns used?
[10:30:28] <temporal_> spriet2000 what do you want to achieve ?
[10:31:39] <spriet2000> firing x async tasks and collect results.. do something when completed
[10:32:09] <spriet2000> and do other stuff with the gathered results
[10:32:57] <spriet2000> just within a verticle
[10:33:23] <temporal_> completion service will not notify you I think
[10:33:56] <temporal_> what do your tasks ?
[10:36:46] <spriet2000> parse for example form data, body data within a request.. cookie data etc..
[10:37:25] <spriet2000> you are right about completion will not notify
[10:38:13] <spriet2000> you have to remember the amount of methods you fire
[10:38:21] <spriet2000> and you collect till its empty i think
[10:39:50] <spriet2000> i am just curious about a good way to do multiple async stuff and collect results.. currently i use a list of futures
[10:40:46] <spriet2000> but its somewhat ugly.. and i think the core team have something developed for it..
[10:41:25] <spriet2000> never mind i will investigate
[10:49:58] <aesteve> spriet2000: is this the kind of stuff you're looking for ? https://github.com/aesteve/vertx-feeds/blob/master/src/main/java/io/vertx/examples/feeds/utils/async/MultipleFutures.java
[10:50:11] <spriet2000> exact
[10:50:30] <spriet2000> i did exact the same :>
[10:50:34] <spriet2000> almost than
[10:50:51] <spriet2000> you are using streams cool
[10:51:25] <aesteve> that seems more natural to me, I used to work in Javascript with underscore/lodash
[10:52:06] <aesteve> (and I used to work with Groovy too, which has the same kind of features)
[10:52:26] <spriet2000> but it aint async right?
[10:52:44] <aesteve> what do you mean ? streams ?
[10:53:24] <spriet2000> will this block the main thread while collecting result?
[10:54:42] <aesteve> there's no result in my implementation, simply indications on whether the whole list has completed or not
[10:59:05] <spriet2000> thanks aesteve i will take a look further .. this is exact stuff i am talking about
[10:59:43] <aesteve> julien suggested to use rxjava, too. Might be a more elegant solution if you want to have a look
[11:00:12] <spriet2000> then you have a complete set of functionality indeed
[11:00:20] <spriet2000> i know rx from c#
[11:00:44] <spriet2000> (a bit ;)
[11:01:37] <aesteve> I think with rxjava you'll have the ability to “join” futures, the same way you can join promises in Javascript ES6
[11:08:16] <spriet2000> cool project btw very informative!
[11:08:27] <aesteve> thanks spriet2000 :)
[11:21:34] <aesteve> problem with my MultipleFutures implementation is I often find myself writing : https://github.com/aesteve/vertx-feeds/blob/master/src/main/java/io/vertx/examples/feeds/verticles/FeedBroker.java#L88-L103
[11:22:27] <aesteve> first I create futures and register them into MultipleFutures then I browse a map and do something forEach future.
[11:22:40] <aesteve> there must be a better way to do this in one single step
[11:24:20] <spriet2000> nice case to investigate!
[11:28:13] <aesteve> in Groovy this would simply be “add(CurriedClosure closure)” instead of “addFuture(Future)” not sure how to mimic that in Java 8
[11:30:24] <aesteve> I'll ask the question on vertx-dev
[11:33:11] <spriet2000> they should give you good advice ..
[11:48:34] <purplefox> temporal_: cescoffier morning folks!
[11:48:53] <cescoffier> purplefox: morning !
[11:48:59] <temporal_> hi everyone
[11:49:12] <purplefox> cescoffier: how is grenoble today?
[11:50:37] <purplefox> we have just had a huge rain storm here
[11:51:16] <cescoffier> purplefox: sunny quite nice actually
[11:52:05] <purplefox> temporal_: cescoffier: ha you southern french with your nice weather, i am jealous
[11:52:17] <temporal_> very sunny today
[11:52:22] <purplefox> does grenoble count as south of france? i guess it is kind of south
[11:52:48] <purplefox> temporal_: it is _always_ sunny in marseille though? ;)
[11:52:57] <cescoffier> it's kind of, but it's not really the south
[11:52:58] <purplefox> like it always rains here
[11:53:07] <temporal_> marseille is statistically the sunniest french city
[11:54:48] <aesteve> mmh storm rain in the UK today means rainy week-end for us in Paris :(
[12:05:02] <purplefox> aesteve: :(
[12:05:09] <purplefox> aesteve: do you live in the city?
[12:05:20] <aesteve> yes
[12:05:44] <purplefox> i think vert.x is being taken over by the french ;) guillaume laforge joked about this on twitter the other day
[12:05:57] <purplefox> something about revenge for waterloo
[12:06:42] <aesteve> according to clich[unknown:eacute]s, this is good news for you, french have good taste, right ?
[12:07:11] <spriet2000> le vertx oulaala
[12:07:27] <purplefox> lol
[12:07:51] <purplefox> it will be good to have 3 hour lunch break anyway ;)
[12:08:02] <purplefox> (cue more stereotypes)
[12:08:38] <aesteve> tbh, try to eat a whole baguette with frogs on it in less than 3 hours, that's a tough one
[12:09:02] <purplefox> true, and even harder when riding a bicycle with string of onions around the neck!
[12:09:17] <aesteve> indeed
[12:19:42] <purplefox> temporal_: julien, i am getting an intermittent failure in MetricsContextTest
[12:19:58] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker
[12:19:58] <purplefox> java.lang.IllegalStateException: ChannelPipeline does not contain a HttpRequestEncoder or HttpClientCodec
[12:20:10] <temporal_> never saw that one
[12:20:13] <purplefox> and the test hangs. it doesn't happen very often though
[12:20:19] <temporal_> I suspect a worker bug again
[12:20:25] <purplefox> yeah, looks like it
[12:20:52] <temporal_> can you show a stack trace ?
[12:21:10] <temporal_> I will try to see if I can reproduce with a test
[12:21:40] <purplefox> unfortunately i didn't see a stack just this in the logs, and I can't easily reproduce it
[12:22:24] <temporal_> ok
[12:22:33] <temporal_> it's a netty log right ?
[12:23:03] <purplefox> ah actually, if you add the @Repeat annotation it is pretty easy to reproduce
[12:23:08] <purplefox> (but you need to copy:
[12:23:22] <purplefox> @Rule
[12:23:22] <purplefox> public RepeatRule repeatRule = new RepeatRule();
[12:23:37] <purplefox> into MetricsCOntextTest as it subclasses AsyncTestBase not VertxTestBase)
[12:23:56] <purplefox> i suspect the log line just logs the message not the stack
[12:25:42] <temporal_> I will investigate it
[13:32:56] <cescoffier> temporal_ purplefox - the openshift quickstart is ready to be reviewed. It's the _simple_ version using the DIY cartridge.
[13:33:01] <cescoffier> https://github.com/vert-x3/vertx-openshift-diy-quickstart
[13:46:03] <purplefox> cescoffier: great stuff!
[13:47:38] <cescoffier> the cartridge is also ready to be reviewed: https://github.com/vert-x3/vertx-openshift-cartridge
[13:48:10] <cescoffier> the cartridge is not usable until it's merged into master - it's because openshift is clone the master branch of the repository
[13:49:15] <cescoffier> on both there is no link on the vert.x version - this is because it uses fat jars. So no need to keep them up to date. (except if we change the vert.x parameter or the format of the cluster.xml file)
[13:50:24] <purplefox> cescoffier: i think we need someone who knows openshift to review this (i.e. not me!) ;)
[13:50:57] <cescoffier> gonna ask the people from openshift directly
[13:51:13] <cescoffier> once merge the quickstart is going to be reviewed as it will be posted on the openshift web site
[13:51:36] <cescoffier> for the cartridge, to use it you just need the link of the manifest
[14:12:57] <purplefox> cescoffier: +1
[14:43:52] <temporal_> purplefox I'm not able to reproduce this bug with the MetricsContextTest, however I more or less see how it happens
[14:44:04] <temporal_> purplefox I'm trying to deduce a reproducer but that's not obvious
[14:44:06] <purplefox> have you tried the @Repeat ?
[14:44:11] <temporal_> 30,000
[14:44:16] <temporal_> on osx
[14:44:18] <temporal_> in a linux vm
[14:44:27] <purplefox> how many cores on the vm?
[14:44:36] <temporal_> I don't know
[14:44:45] <purplefox> default is usually low so bad for race conditions
[14:44:49] <purplefox> have you tried on osx?
[14:44:51] <temporal_> good advice
[14:44:57] <temporal_> yes on osx too
[14:44:59] <temporal_> does not happen
[14:45:17] <temporal_> it's quite tiny window I suspect
[14:46:09] <purplefox> which test are you testing again?
[14:46:23] <temporal_> testHttpClientWebsocketWorker
[14:46:36] <purplefox> weird, it fails pretty quickly for me:
[14:46:56] <temporal_> I whish it would
[14:47:06] <temporal_> I can provide a branch with some changes
[14:47:13] <temporal_> and you can test it to see if it fixes it
[14:47:21] <temporal_> (does not mean I will not have a proper test for it)
[14:47:21] <purplefox> * Iteration 1/1000 of test [14:47:23] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker [14:47:25] <purplefox> log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFactory). [14:47:27] <purplefox> log4j:WARN Please initialize the log4j system properly. [14:47:29] <purplefox> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. [14:47:31] <purplefox> * Iteration 2/1000 of test
[14:47:33] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker
[14:47:37] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker
[14:47:39] <purplefox> * Iteration 3/1000 of test
[14:47:40] <temporal_> I believe you
[14:47:41] <purplefox> * Iteration 4/1000 of test
[14:47:43] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker
[14:47:45] <purplefox> * Iteration 5/1000 of test [14:47:47] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker [14:47:49] <purplefox> Starting test: MetricsContextTest#testHttpClientWebsocketWorker [14:47:51] <purplefox> * Iteration 6/1000 of test
[14:47:53] <purplefox> java.lang.IllegalStateException: ChannelPipeline does not contain a HttpRequestEncoder or HttpClientCodec
[14:47:55] <purplefox> silly question: are you uptodate with master?
[14:47:57] <purplefox> ok sure
[14:48:02] <temporal_> I will update with master
[14:48:21] <temporal_> I'm up to date
[14:48:54] <purplefox> anyone good news i, after the last week or more we have now cleared almost all outstanding bugs on core and other projects :)
[14:49:05] <purplefox> i lose count how many now
[15:02:44] <purplefox> temporal_: can you send me a link to your fixes?
[15:02:58] <temporal_> I haven't yet written it
[15:03:11] <temporal_> I can try to make a gross one
[15:03:14] <temporal_> quickly
[15:03:21] <temporal_> just to see
[15:04:00] <temporal_> I'm goint to do that
[15:08:18] <temporal_> it's actually a logical fix with respect to other fixes
[15:08:41] <temporal_> (i.e the same kind)
[15:08:49] <cescoffier> temporal_or purplefox can you give my the commit right on vertx-examples ?
[15:10:54] <temporal_> cescoffier will do now
[15:10:59] <temporal_> purplefox try that please : https://github.com/eclipse/vert.x/tree/websocket-worker-client-connected-fix
[15:11:01] <cescoffier> thanks temporal_
[15:11:36] <temporal_> cescoffier check
[15:12:29] <cescoffier> temporal_ works thanks !
[15:13:12] <cescoffier> what's the review policy for examples ? I've added an example of verticle reading the configuration in the maven-verticle module
[15:13:35] <temporal_> cescoffier at the moment we fully trust you
[15:13:49] <cescoffier> ok But don't trust my markdown skills….
[15:14:40] <cescoffier> ah ah ah… it's asciidoc, not markdown
[15:24:11] <purplefox> cescoffier: temporal_ guys - one thing that we need to do for the 3.0 release is complete the Eclipse release process as its a major release
[15:24:43] <cescoffier> any document about that ? (only know the Apache process)
[15:24:47] <purplefox> this is basically a matter of filling in a few forms, ticking some boxes and sending some emails to various people
[15:25:23] <purplefox> I did this last time, so it's down to one of you to have the pleasure of it this time ;)
[15:25:45] <purplefox> I suggest Julien as he is more familiar with the project, but you can fight amongst yourselves to decide who ;)
[15:26:16] <temporal_> when should that happen ?
[15:26:21] <cescoffier> well… I don't want to steal this pleasant activity to Julien
[15:26:23] <purplefox> I've also suggested that we get someone who knows the process to mentor the person
[15:26:25] <temporal_> keep in mind I'm travelling the week of the release
[15:26:34] <purplefox> travelling?
[15:26:38] <temporal_> meeting
[15:26:48] <purplefox> ah sereca
[15:26:50] <purplefox> ok
[15:27:12] <purplefox> well you just need an internet connection so i guess it should be ok
[15:27:30] <temporal_> I'll do my best
[15:27:37] <temporal_> I'll start to study that soon
[15:27:41] <temporal_> and prepare it in advance
[15:30:03] <purplefox> ok thanks julien, i'll put you in touch with max who can help you out with any questions
[15:32:54] <temporal_> purplefox have you checked the fix on the branch ?
[15:33:21] <purplefox> not tried it yet, will now :)
[15:33:26] <temporal_> ok
[15:33:39] <temporal_> I have an idea for a reproducer
[15:33:44] <temporal_> not sure it will work out
[15:40:26] <purplefox> temporal_: the fix doesn't help
[15:40:34] <temporal_> ok
[15:40:55] <purplefox> temporal_:i suggest if it's not easy to fix that we don't spend too much time on it now, probably other more important stuff to do :)
[15:41:23] <temporal_> purplefox yep
[15:41:56] <purplefox> are you handing the mongo client date issue?
[15:42:06] <temporal_> purplefox not yet
[15:42:11] <temporal_> purplefox can you take care of it ?
[15:42:24] <purplefox> ok, if you look at the groovy json issue :)
[15:42:31] <temporal_> no problem
[15:42:41] <temporal_> I thought that JsonObject.getMap was fully unwrapping things
[15:43:59] <purplefox> yeah i don't get it, jsonobject does not contain nested jsonobjects anyway, it contains maps
[15:43:59] <temporal_> (I think this is what it is about)
[15:45:17] <purplefox> ah bollocks. i just remembered… i can't do the milestone release on monday as i am in meetings in newcastle (monday and tuesday) :(
[15:47:42] <purplefox> for some reason in the next few weeks everyone has thought it a good idea to book all the meetings :( [newcastle,customers, sereca,msa]
[15:48:32] <purplefox> it's actually really getting on my tits
[15:49:54] <rajith> purplefox: I was hoping you would be free next week so I can heap more misery on you by asking you to review the amqp support work
[15:50:06] <purplefox> ha you're kidding right?
[15:50:11] <rajith> purplefox: but I will be at a customer site too .. so will make it a point to bug u the week after
[15:50:44] <rajith> purplefox: well u said tits and that got my attention :p
[15:50:51] <purplefox> right now everyone is telling me their stuff is the most important and it gets priority ;)
[15:51:01] <temporal_> purplefox did I ?
[15:51:09] <purplefox> no, not you
[15:51:17] <purplefox> or rajith actually
[15:51:27] <rajith> purplefox: hahahah
[15:51:33] <purplefox> I'm mainly pissed about others who will remain nameless on this public channel ;)
[15:53:04] <rajith> purplefox: lol
[15:54:18] <rajith> purplefox: I understand that u and julien are overwhelmed by the core work. So no hurry .. but I'll bug u here and there occasionally to get your attention
[15:55:20] <purplefox> so end result is, if we want to get everything done that means we have to work all night and all weekend. but guess what? we're already doing that. so unless we can break the laws of physics. bangs head on desk ;)
[15:56:53] <rajith> purplefox: yea Julien told me how tough the situ is … I've communicated that to ted and david when they asked about vertx-amqp work. I'm sure people understand
[15:57:03] <rajith> purplefox: unless they find a way to clone u guys
[15:57:44] <rajith> purplefox: btw do we have customers using vertx? an SA guy from toronto asked about vert.x during a casual conversation
[15:59:11] <purplefox> rajith: *lots* of people use Vert.x, we have some names already up on the vert.x 3 website (scroll down) http://vert-x3.github.io/ and a load more who arene't up there. some very big names, i'll tell you some more privately
[15:59:12] <temporal_> rajith check vert-x3.github.io bottom of the page for customers
[15:59:22] <temporal_> I mean public customers
[16:00:57] <aesteve> big names on the vertx-3 website would help spread the word. People tend to follow trending technologies these days
[16:01:04] <aesteve> (there already are)
[16:01:47] <rajith> temporal_: purplefox awesome!
[16:01:50] <purplefox> rajith: i sent you a private email too
[16:02:24] <rajith> purplefox: I already did some selling to the SA guy.
[16:02:39] <rajith> purplefox: thx for the email
[16:03:45] <purplefox> inside Red Hat we don't have much exposure I guess because there is no product. but in terms of mindshare I'd say Vert.x is probably one of the most popular projects that Red Hat invests in.
[16:04:08] <purplefox> we have more stars on github than any jboss project (almost 3 times as many as app server for example)
[16:05:53] <rajith> purplefox: yea the SA guy wanted to know about when we are going to productize it .. I said he should speak Mark L/you
[16:07:32] <temporal_> purplefox JsonObject stores nested JsonObject either as Map or JsonObject, should we make this consistent or have groovy do its own map conversion ?
[16:12:28] <purplefox> i think it is done this way to prevent too much copying
[16:13:34] <purplefox> could you create a map subclass that converts when required?
[16:16:03] <purplefox> basically override the get method and check if jsonobject and convert
[16:17:22] <temporal_> ok
[16:20:01] <purplefox> i dunno, just a suggestion, i'm sure you will work something ouy
[16:20:28] <purplefox> so just remembering…
[16:20:50] <purplefox> i think we allow nested maps as that is more efficient, e.g. when getting a query from mongodb we don't have to do much conversion
[16:21:17] <purplefox> and we allow nested jsonobject as that's more efficient for user created nested jsonobjects
[16:22:41] <purplefox> maybe we could be consistent in jsonobject and only store nested maps
[16:22:58] <purplefox> i'm not sure it would be a big overhead to crete the jsonobject wrapper in the get method…
[16:24:57] <temporal_> basically when getMap() is invoked
[16:25:09] <temporal_> nested json is either a Map or a JsonObject
[16:25:28] <temporal_> so yes either we store eerything as a Map
[16:25:35] <temporal_> (and we can call getMap on JsonObject on a put)
[16:25:43] <temporal_> since the map already exists
[16:25:57] <purplefox> yeah i meant call getMap on JsonObject on put
[16:26:04] <temporal_> I'm going to do that then
[16:26:26] <purplefox> but first… can you do a quick microbenchmark or something to see performance overhead?
[16:26:52] <purplefox> because the get will require creation of an object wrapper
[16:27:09] <temporal_> I mean store as Map
[16:27:20] <purplefox> yess
[16:27:27] <temporal_> if user do a put on JsonObject, the underlyhing Map already exists in the JsonObject iself
[16:27:31] <purplefox> yes
[16:27:36] <purplefox> but when they call get
[16:27:44] <purplefox> it will need to create a jsonobject wrapper around the map
[16:27:49] <purplefox> which it currently doesn't need to
[16:27:49] <temporal_> ah yes it recreates a JsonObject on each call
[16:27:58] <purplefox> so that's the overhead
[16:27:58] <Sticky> ooi are you trying to address the same issue we had in the 2.0 mongo persistor of supporting mongo specific json types?
[16:28:09] <temporal_> perhaps we can use a Map subclass that caches the JsonObject
[16:28:51] <temporal_> Sticky we do have JsonObject in V3 that stores nested json as Map or JsonObject
[16:29:02] <temporal_> in groovy we just call getMap to get a Map
[16:29:10] <temporal_> and user expects nested Map
[16:29:14] <purplefox> yeah that was the other suggestion (above)
[16:29:24] <purplefox> but it's more work as you'd have to subclass several methods
[16:29:30] <purplefox> e.g. the iterators, and values() etc
[16:30:08] <temporal_> it would be only for caching the JsonObject in JsonObject.getMap or getValue
[16:30:36] <temporal_> i.e optimize that
[16:30:37] <temporal_> if (val instanceof Map) {
[16:30:37] <temporal_> val = new JsonObject1);
[23:20:29] <purplefox_> it must just be simpler to convert to a jsonobject on get always
[23:20:37] <purplefox_> i'm not sure the overhead would be too bad
[23:21:04] <temporal_> indeed it does
[23:21:04] <temporal_> public void renderJsonObjectToString(ExpressionModel expression, CodeWriter writer) {
[23:21:04] <temporal_> expression.render(writer);
[23:21:05] <temporal_> writer.append(“.toString()”);
[23:21:05] <temporal_> }
[23:21:25] <temporal_> it's code translator
[23:22:22] <temporal_> it's how encodePrettily is translated in groovy
[23:23:37] <temporal_> I should use this I thnk
[23:23:37] <temporal_> http://docs.groovy-lang.org/latest/html/gapi/groovy/json/JsonOutput.html
[23:24:07] <purplefox_> why not just keep things simple, forget the JsonMap and always store internally as a map, and extract the map from the jsonobject on put?
[23:24:45] <temporal_> it's not about what we changed in this case
[23:25:18] <temporal_> purplefox_ as you want
[23:25:31] <temporal_> either case, this current bug in codetranslator will happen
[23:25:38] <purplefox_> just a suggestion
[23:25:40] <temporal_> I'm not against getting it simpler
[23:25:45] <temporal_> if that does not hurt performance
[23:25:46] <temporal_> anyway
[23:25:49] <purplefox_> you do what you think is right :)
[23:26:01] <temporal_> recursively it will unwrap to map
[23:26:05] <purplefox_> tbh i would doubt the perf diff is great
[23:26:06] <temporal_> I mean first level is json
[23:26:17] <temporal_> when we decode
[23:26:31] <temporal_> but nested json are map or lists
[23:26:38] <temporal_> when deserialized by jackson
[23:46:44] <temporal_> when you type “cd java” in your browser address bar, it means it's time to go to bed