This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[00:26:08] <AlexLehm> hm, CaseInsensitiveHeaders doesn't seem to support .equals()

[00:26:18] <AlexLehm> assertEquals(new CaseInsensitiveHeaders(), new CaseInsensitiveHeaders()); fails

[01:15:24] <grant_> Hello, Is io.vertx:vertx-auth:3.0.0-SNAPSHOT broken at the moment? I cannot compile my vert-web project because it says it can not resolve that dep

[01:15:36] <grant_> the same project compiled fine last night

[10:14:57] <cescoffier> I've written a guide to publish a vert.x 3 app on openshift using the DIY cartridge:

[10:20:27] <aesteve> thx cescoffier I found myself doing that months ago :)

[10:20:32] <aesteve> just a quick question though

[10:21:05] <aesteve> I used directly OPENSHIFT_DIY_IP, not http.address as you did, is it a bad practice ?

[10:22:25] <cescoffier> well, no, it also works, but then your application is bound to openshift

[10:23:08] <cescoffier> using http.port and http.address let you use other hosting system (Heroku[unknown:hellip])

[10:23:59] <cescoffier> So, I prefer not binding my application to a specific cloud provider

[10:25:06] <cescoffier> (it's also a matter of taste ;-) )

[10:25:45] <aesteve> ok thanks for the clarification, I abstracted this in an other way, but properties must be better :)

[10:26:57] <aesteve> that's a good advice anyway, thanks and gj with your doc it's easy to read and covers pretty much everything I think

[10:33:57] <cescoffier> thanks, next step is to provide a cartridge

[10:36:58] <aesteve> I'm just being curious here, you'll go with one cartridge per language ?

[10:38:04] <cescoffier> My first idea is to use the 'fat' jar approach

[10:38:22] <cescoffier> so only one cartridge would be required

[10:39:06] <aesteve> so if, locally, I'm using “vertx run myVerticle.rb” how would it be “translated” with the fatJar approach ?

[10:41:56] <aesteve> (but nvm, this is just pure curiosity, I don't want to waste your time at all ! I'll see anyway when you're finished with the cartridge)

[10:46:23] <cescoffier> I'm not quite sure yet (still trying to see what we can do with a cartridge). In your case, you just create a fat jar embedding your ruby file and packaging all the dependencies. To create fat jar you can use Maven or Gradle.

[10:47:43] <cescoffier> temporalfox knows more about the fatjar creation

[10:48:00] <aesteve> yeah I would do that if I had to. My point was just that I was afraid people would expect the cartridge to work as the “vertx run” command line (I wasn't asking for my own purpose ;) )

[10:48:10] <temporalfox> hi

[10:48:17] <temporalfox> what is the exact question :-) ?

[10:49:05] <cescoffier> is it possible to create a fatjar for ruby verticle ?

[10:50:51] <temporalfox> yes I think if you use the manifest main verticle

[10:51:00] <temporalfox> and the vertx starter

[10:51:15] <temporalfox> you use in the MANIFEST.MF Main-Class : the starter class

[10:51:28] <temporalfox> and you add a Main-Verticle: foo.rb

[10:52:05] <temporalfox>

[10:52:05] <aesteve> is this what happens behind the hood when you do : “vertx run myVerticle.rb” ?

[10:52:13] <temporalfox> yes

[10:52:28] <temporalfox> vertx run : runs the Starter class main

[10:52:33] <aesteve> ok nice, so that's the perfect approach for a “generic” vertx cartridge indeed

[10:53:23] <cescoffier> actually, in the docker image, we use vertx run

[12:43:36] <purplefox> temporalfox: hi julien

[12:43:57] <temporalfox> purplefox hi

[12:44:04] <purplefox> temporalfox: how are you?

[12:44:07] <temporalfox> good

[12:44:22] <purplefox> great

[12:45:02] <purplefox> temporalfox: i had a little hack on that hazelcast asycc multimap subs issue (you might have seen the link i added to your pr)

[12:45:13] <temporalfox> yes

[12:45:39] <purplefox> i'm running it in a loop here, and its at iteration 48 with no failures

[12:45:48] <temporalfox> ok

[12:45:49] <purplefox> (before it would fail in 1 or 2 iterations)

[12:48:33] <temporalfox> looks simpler than what I did

[12:50:05] <temporalfox> is it a fix ?

[12:50:19] <temporalfox> I see in inprogressCount shared

[12:51:37] <purplefox> could you run it yourself so we know it works on OSX? (Just right click and run in your IDE)

[12:51:47] <purplefox> I have the repeat rule already in there

[12:52:12] <purplefox> it's quite important to avoid synchronized blocks on the main get() path

[12:52:16] <purplefox> as this will be called a lot

[12:52:49] <temporalfox> it runs on osx

[12:53:50] <purplefox> good. how many iterations?

[12:56:45] <temporalfox> 20 at the moment

[13:34:05] <temporal_> is inProgressCount intended to be shared between different keys ?

[13:39:02] <AlexLehm> aesteve: i believe you mentioned a few days back, i have given that a try with vertx and I would think it doesn't require a special package since this usually clones a github repo as basis for the development

[13:39:21] <AlexLehm> i could get it working due to the memory contraints of the free version though

[13:39:54] <aesteve> ah do you remember that ? I had forgotten tbh. I'll write it down somewhere and give it a try myself

[13:40:12] <aesteve> thansk :)

[13:40:29] <AlexLehm> i tried that out maybe a day after i read your msg (i meant to do that anyway), but then I forgot who actually wrote the question

[13:41:00] <AlexLehm> thanks to the irc archive, i found the message again :-)

[13:41:12] <aesteve> good investigation !

[13:41:36] <AlexLehm> the platform is quite nice with a browser frontend for a bash on ubuntu

[13:44:06] <aesteve> indeed

[13:44:31] <aesteve> my idea was to submit many vertx examples (from the examples repo)

[14:01:45] <purplefox> temporal_: it is shared between keys but i don't think that matters

[14:01:54] <temporal_> purplefox ok

[14:02:08] <purplefox> are you happy for this to be merged?

[14:02:26] <temporal_> yesterday when I tried this way, I did not share it and it was not really possible to achieve it

[14:02:36] <temporal_> purplefox yes it looks good

[14:19:07] <purplefox> temporal_: I'm going to look at the remaining executeOnIO issues. is there a PR somewhere that has all the tests and your proposed fixes?

[14:19:30] <temporal_> purplefox good question :-)

[14:20:22] <temporal_> so there are at the moment two branches pushed

[14:20:34] <temporal_> one contains 3 reproducers + 2 fixes

[14:20:42] <temporal_> that's the branch to handle

[14:21:48] <temporal_> however the other branch contains a reproducer for the same issue that is not fixed in the first branch, but this reproducer is a more straightforward way to do with an HttpServer that sends a buffer with the handshake + websocket frame , I think it would be good to keep it as additional care

[14:22:39] <purplefox> any chance you could put everything in one branch and push that?

[14:23:06] <temporal_> ok

[14:23:16] <temporal_> I'l going to cherry pick that commit

[14:29:20] <temporal_> purplefox here it is :

[14:30:03] <purplefox> thanks

[14:30:27] <purplefox> can you submmit a pr for it?

[14:33:41] <temporal_>

[14:33:41] <purplefox> temporal_: i created a pr for that but there seems to be other non related commits in there (recordparser stuff)

[14:33:52] <temporal_> purplefox funny

[14:34:00] <temporal_> isn't the parser already merged ?

[14:34:17] <temporal_> perhaps I need to rebase

[14:34:39] <purplefox> i've no idead what the recordparser change is

[14:34:51] <temporal_> it's a VertxGenisation

[14:35:38] <temporal_> it should be clean now

[14:37:18] <purplefox> temporal_: this PR doesn't seem to contain the websocket fixes

[14:37:47] <temporal_> I haven't done websocket fixes and left them to you

[14:38:06] <temporal_> should I try to do them ?

[14:38:23] <temporal_> I think it's better you handle them yourself though

[14:38:24] <purplefox> i'm looking for a single branch where all the tests and proposed fixes are in there

[14:38:50] <temporal_> this branch

[14:39:07] <purplefox> basically all the tests and fixes but without any other stuff mixed in i.e. no metrics stuff, recordparser or whatever

[14:39:08] <temporal_> has 2 fixes + tests and 2 reproducer for the same bug

[14:39:53] <temporal_> there is no metrics / recordparser stuff

[14:40:02] <purplefox> but there is also no websocket fix

[14:40:10] <temporal_> you said you wanted to do it :-)

[14:40:13] <purplefox> but there is a websocket test, so i am very confused

[14:40:31] <temporal_> yes because I wanted fist to exhibit this bug so we can talk about it like we did yesterday

[14:40:47] <temporal_> the other were quite trivial to fixes

[14:41:02] <purplefox> basically the issue i had with the original PR is it had other stuff mixed up in it

[14:41:41] <temporal_> the very original PR did not have proper reproducer for these issues

[14:41:55] <temporal_> I wrote them when travelling last week

[14:42:07] <purplefox> the simple fixes to netclient/netserver we discussed yesterday and you can just merge them, i am not interested in them

[14:42:13] <temporal_> ok

[14:42:20] <purplefox> aiui, the only remaining thing to look at is the websocket fix

[14:42:21] <temporal_> so how about I do that

[14:42:29] <temporal_> ok

[14:42:40] <purplefox> so i'm looking for a pr that contains the websocket fix plus all the tests for it, but nothing else

[14:42:46] <temporal_> so let me clean that and make another PR with websocket bug + fix

[14:42:56] <purplefox> then we can look at that and review it and comment on it, without being confused by other non related stuff

[14:44:45] <temporal_> sure

[14:50:37] <purplefox> temporal_: sorry about all this, but hopefully we will have it out of the way soon. I'm sure we will both be glad of that! ;)

[14:51:01] <temporal_> yeah :-)

[15:09:11] <temporal_> purplefox here it is :

[15:24:26] <purplefox> temporal_: the python tests runner changes you did on vertx-web cause the test to fail on my machine

[15:24:34] <purplefox> temporal_: don't worry i can fix them

[15:25:32] <temporal_> because of

[15:25:33] <temporal_> new File(“src/test/sockjs-protocol/venv/lib/python2.7/site-packages”).getAbsolutePath()

[15:25:33] <temporal_> ?

[15:25:53] <purplefox> yeah it doesn't like the “PYTHONPATH=” bit

[15:26:04] <purplefox> i reverted it back to how it was before (for linux) and it works

[15:26:26] <temporal_> ok

[15:29:02] <purplefox> temporal_: ok will take a look at the executeOnIO now

[15:52:44] <purplefox> temporal_: I've gone through the logic of the websocket context fix, and it looks ok I think :)

[15:53:01] <temporal_> purplefox cool, I'm relieved

[15:53:19] <purplefox> i though perhaps it needed further synchronization but i don't think so

[15:54:09] <purplefox> i actually really hate all that netty websocket/http code, it's really ugly

[15:54:22] <temporal_> I agree it's quite hard to follow

[15:54:33] <temporal_> at the same time, I think it's part of the value Vert.x adds

[15:54:35] <purplefox> one day we should refactor it, but the netty api doesn't make writing pretty code easy

[15:55:15] <purplefox> btw, on an unrelated note one of the metricstests fails for me intermittently - this has been happening for ages

[15:55:15] <purplefox> now it fails most of the time

[15:55:31] <temporal_> ok, can you show me the failure ?

[15:55:36] <temporal_> do you know why it fails ?

[15:56:15] <temporal_> they don't for me, I'll run them in a linux image

[15:56:53] <purplefox> testHandlerProcessMessage

[15:56:58] <purplefox> you need to run it in a loop

[15:57:00] <temporal_> ok

[15:57:06] <temporal_> yes good idea

[15:57:13] <purplefox> just do this:

[15:57:13] <purplefox> @Test

[15:57:14] <purplefox> @Repeat(times = 10000)

[15:57:14] <purplefox> public void testHandlerProcessMessage() {

[15:57:14] <purplefox> testHandlerProcessMessage(vertx, vertx, 1);

[15:57:14] <purplefox> }

[15:57:16] <temporal_> I'll spend time on this after the worker fixes

[15:57:18] <purplefox> then run in the IDE

[15:57:38] <temporal_> ah btw

[15:57:58] <temporal_> at some point I suggested to name the anonymous UUID internal to vert.x with a prefix

[15:58:16] <temporal_> like event bus reply handlers ids

[15:58:26] <temporal_> or netsocket event bus registrations

[15:58:53] <temporal_> for instance “vertx.eb.reply” + UUID

[16:12:01] <temporal_> purplefox when I'm running vertx core testsuite I get 1 error and 2 failures for JsonObjectTest

[16:12:14] <temporal_> purplefox however if I only run -Dtest=JsonObjectTest it passes

[16:12:22] <purplefox> can you provide some more details?

[16:13:06] <temporal_> quickly here is one of them :

[16:13:36] <temporal_> I'm running it fully again to get proper info

[16:14:05] <purplefox> temporal_: you merged the webcsocket fix? i was just doing a few tweaks and merging here :(

[16:14:12] <temporal_> ah sorry

[16:14:47] <temporal_> what should I do ?

[16:15:03] <purplefox> doesn't matter, i can merge it again

[16:18:08] <purplefox> temporal_: pull and try again

[16:18:30] <temporal_> here we go

[16:21:03] <temporal_> purplefox passes fully now

[16:22:09] <temporal_> purplefox can you uncomment the MetricsContextTest and try again ? I believe these should pass now

[16:22:16] <purplefox> temporal_: i think the metrics test fails sometimes because you increment the end count for the handler metric after the message has been handled, but in that time the reply message could have been sent back and processed

[16:22:33] <temporal_> purplefox ok I'm taking notice and will update

[16:22:51] <purplefox> so basically the test is currently non deterministic as it relies on timing

[16:26:29] <purplefox> temporal_: MetricsCOntextTest fails for me

[16:26:39] <temporal_> it hangs ?

[16:27:19] <purplefox> no, i fails

[16:27:25] <purplefox> does it not fail for you?

[16:27:31] <temporal_> I'm trying again

[16:27:37] <purplefox> make sure you have git pull core

[16:27:44] <temporal_> it fails too

[16:27:56] <purplefox> unexpected null context

[16:27:58] <temporal_> but that is probably a test issue that got changed

[16:28:02] <temporal_> because of timing

[16:28:06] <temporal_> and worker fixes

[16:28:09] <temporal_> Starting test: MetricsContextTest#testHttpClientWebsocketWorker

[16:28:11] <temporal_> recently

[16:28:14] <temporal_> need to adjust the test

[16:28:59] <purplefox> yeah, expected null doesn't seem right

[16:29:06] <temporal_> before yes :-)

[16:32:20] <temporal_> actually I need now to call back the metrics SPI in the io block

[16:32:29] <temporal_> and not in the constructor

[16:35:15] <purplefox> temporal_: it shouldn't be necessary to call the metrics api create and close from the context thread

[16:36:17] <temporal_> do you mean that we should try to do always with the event loop thread when it''s a worker context ?

[16:36:21] <purplefox> i can understand why you want to say that actual performance sensitive metrics methods should be called on the same thread, but close and create, it's not necessary

[16:36:32] <temporal_> it's connected :-)

[16:36:41] <purplefox> no, i am just saying that there is no point in making constraints on create and close thread

[16:36:45] <temporal_> ok

[16:36:48] <purplefox> it just adds complexity

[16:36:50] <temporal_> I'm going to release them in the test

[16:36:56] <temporal_> and update javadoc

[16:37:23] <purplefox> if we are calling metrics close or metrics create anywhere in core from executeFromIO we should probably remove the executeFromIO

[16:38:22] <temporal_> I just wanted to move this in the same executeFromIO block of the websocket handle

[16:38:27] <temporal_> i.e have

[16:38:28] <temporal_> context.executeFromIO1);

[16:38:28] <temporal_> wsConnect.handle(webSocket);

[16:38:28] <temporal_> });

[16:38:30] <temporal_> instead of

[16:38:35] <temporal_> context.executeFromIO(() → {

[16:38:35] <temporal_> log.debug(“WebSocket handshake complete”);

[16:38:35] <temporal_> wsConnect.handle(webSocket);

[16:38:35] <temporal_> });

[16:39:12] <temporal_> without any extra executeFromIO call

[16:41:07] <purplefox> if there's no *extra* executeFromIO call that's fine. it's just if you're doing an executeFromIO only to call metrics close that's unnecessary

[16:41:58] <temporal_> ok

[16:46:43] <purplefox> temporal_: i've fixed the non deterministic metrics test too

[16:46:54] <temporal_> thanks

[18:13:57] <aesteve> purplefox: I'm starting to be concerned about the Gradle issue with vertx-auth, that's the third person on the Google Group to have the same issue

[18:14:52] <aesteve> I hope this won't be an issue in milestone 6 and is indeed due to the changes/caches with SNAPSHOTS but I'm starting to think it's not

[18:14:56] <aesteve> I'll try to investigate

[18:46:26] <purplefox> aesteve: arnauld, do you have a reproducer for it?

[18:47:01] <aesteve> I'll send one, gimme a sec

[18:48:41] <aesteve> ok perfect

[18:49:04] <aesteve> just checkout :

[18:49:17] <aesteve> (the sse implementation i did like 2 weeks ago)

[18:49:34] <aesteve> and simply “./gradlew compileJava”

[18:49:38] <aesteve> you'll get the error

[19:04:28] <aesteve> purplefox: I'm here for half an hour still then I'll go home. Tell me if you need anything, I can come back on IRC when I come home

[19:17:15] <purplefox> aesteve: ok will take a look now

[19:18:35] <purplefox> aesteve: how do you import it in the IDE. I always seem to have problems with gradle

[19:23:22] <purplefox> aesteve: are you there?

[19:24:06] <aesteve> sorry

[19:24:09] <aesteve> ./gradlew idea

[19:25:05] <purplefox> aesteve: ok, the problem is that there is no mavenLocal() in your build.gradle file

[19:25:12] <purplefox> so it won't look in the local maven repo

[19:25:24] <aesteve> why would I need that ?

[19:25:29] <purplefox> so it only looks in remote maven, and that's got the old artifact in it

[19:25:38] <purplefox> if i add mavenLocal()

[19:25:41] <purplefox> it works fine

[19:25:45] <purplefox> with the latest vertx-web

[19:26:05] <aesteve> ok so this means this won't be an issue with milestone 6 ?

[19:26:32] <purplefox> it's not an issue ;)

[19:26:41] <aesteve> I don't understand…

[19:26:51] <purplefox> if you're using development stuff you may well need to build latets snapshots

[19:26:56] <aesteve> ok

[19:27:01] <purplefox> don't assume they've all been pushed

[19:27:12] <purplefox> so your example uses vertx-web

[19:27:28] <purplefox> and it just so happens we've been refactoring that a lot recently and the poms have changed

[19:27:35] <purplefox> but it looks like the latest pom is not pushed remotely

[19:27:41] <purplefox> so you were picking up an old pom

[19:28:01] <purplefox> in this case the easiest thing to do is just to

[19:28:06] <purplefox> “mvn install” in vertx-web

[19:28:10] <purplefox> that puts it in your local repo

[19:28:44] <aesteve> I'll try to mvn publish (since we're some collaborators working on the same nexus repo)

[19:28:46] <purplefox> i'll try and figure out why it's not pushed. probably because CI has done it for some reason

[19:28:55] <purplefox> not done it i mean

[19:29:23] <aesteve> until recently, it was working fine with the maven { url '' }

[19:29:52] <aesteve> it was always up-to-date and I didn't face any issue, it's probably the refactoring indeed

[19:30:25] <aesteve> anyway thanks a lot for your help, i'lll build publish regularly until then final release

[19:30:27] <purplefox> aesteve: there's a lot of churn at the moment

[19:30:39] <purplefox> the safest thing to do is to build the dep yourself if you're having issues

[19:32:07] <aesteve> or I'll stick to milestones, idk

[19:32:34] <aesteve> maybe for my own projects (like SSE, Nubes, the webRTC impl) I'll build locally

[19:32:48] <aesteve> for corporate projects I'll stick to milestones

[19:35:46] <purplefox> aesteve: of course I wouldn't expect anyone to use development branches in production, that would be kind of insane ;)

[19:36:33] <purplefox> so if you're using development branches there are no guarantees, anything could change at any time. that goes with the territory, nothing unusual in that

[19:36:52] <aesteve> it's not production yet obviously, but that'll be coordinated with 3.0 release (I hope)

[19:36:55] <aesteve> :)

[19:37:02] <purplefox> also milestones - they are just that milestones, think of them like alphas and betas

[19:37:48] <aesteve> that's exacctly what we want for milestones, this is really the very first issue I've had so far with the snapshots btw and I'm using them since 'round december

[19:42:47] <aesteve> some people have started asking me questions about the vertx-feeds example, too. That's kinda good news

[19:50:17] <aesteve> good evening purplefox and thanks again for your help.

) → { [16:38:28] <temporal_> log.debug(“WebSocket handshake complete”); [16:38:28] <temporal_> webSocket.setMetric(metrics().connected(metric(), webSocket