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

[11:37:26] <Wei_> Hello. Anyone would like to help me with sql client vertx?

[12:00:38] <AlexLehm> Wei_: have not really used that yet, but please go ahead

[12:01:23] <Wei_> Thanks.

[12:01:57] <Wei_> AlexLehm: When I feed the update with correct parameters, sometimes the update is not executed.

[12:04:33] <AlexLehm> are you getting a success result when the update is not executed?

[12:05:36] <AlexLehm> or better are you getting a result at all when the update is not executed?

[12:09:47] <Wei_> AlexLehm, Yes. I am. but not the updated result.

[12:12:11] <AlexLehm> i mean, you do something like connection.query(“UPDATE x …”, res → {});

[12:12:16] <AlexLehm> what is res returning

[12:12:46] <Wei_> it's returning a result whose updated rows is 1.

[12:12:58] <AlexLehm> which would be correct for the query?

[12:13:20] <AlexLehm> which is what you expect i mean?

[12:13:20] <Wei_> some fields are supposted to be updated, but they are not.

[12:13:47] <Wei_> The odd thing is that not all updates were failed.

[12:14:47] <Wei_> Say I have a status column in the table. The status is updated to be “started”, “processing”, “complete”.

[12:15:22] <AlexLehm> ok, does this happen all the time when you execute the operation? Could you put up a small project that shows the issue including the table defintion for the db?

[12:15:24] <Wei_> The last update to “complete” sometimes is not executed.

[12:15:56] <Wei_> no. the behavior is irregular.

[12:16:38] <Wei_> Let me see

[12:17:26] <AlexLehm> which database are you using?

[12:17:38] <Wei_> postgresql

[12:18:16] <Wei_> AlexLehm, are you still here in a hour?

[12:18:45] <AlexLehm> yes, i have a day off today, so i have some time to spend on vert.x

[12:19:57] <Wei_> thanks. I just grab some lunch to get back to you.

[12:22:48] <AlexLehm> cescoffier: do you use a specific profile for the sonarqube analysis? when I run findbugs, I get errors probably because the plugin doesn't handle Java 8

[12:57:11] <wei_> AlexLehm, are you there?

[12:57:17] <AlexLehm> yes

[12:58:18] <wei_> Do you need more info from me?

[12:59:46] <AlexLehm> i think it would best if you could create a small project without confidential elements that has the issue and put that up somewhere (preferably on github) so i can try to run it

[13:01:14] <wei_> I would love to. But it would still involve a lot of components to produce the issue. I would suggest we just use teamviewer. Is that Ok?

[13:04:03] <AlexLehm> sure that should work

[13:05:09] <wei_> Great. I will let you know when I'm ready.

[13:05:36] <AlexLehm> ok, as usual Teamviewer wants to update, i will be online in a few minutes

[13:05:49] <wei_> Sure.

[13:09:38] <AlexLehm> ok, i have teamviewer running, however i will have to assist my gf in preparing lunch a bit, we may have to postpone the session for an hour or so

[13:12:51] <wei_> Np. please let me know when you are back. :)

[13:33:02] <cescoffier> AlexLehm : It uses the -Pcoverage profile, but that's only for jacoco

[13:53:40] <AlexLehm> cescoffier: i have added findsbugs maven report plugin in the pom, which works, but i am not sure how sonarqube creates the reports

[13:53:49] <AlexLehm> doesn't really matt#er though

[13:54:44] <AlexLehm> cescoffier: i have another question btw, i went through your comments for the mail-client pr, i am not sure if I understood the last comment about the headers correctly

[13:54:57] <AlexLehm> wei_: i am back

[13:56:35] <cescoffier> AlexLehm : it does not use findbugs anymore, they have their own checker

[13:56:41] <cescoffier> AlexLehm : they implemented most of the findbugs rules

[13:57:04] <AlexLehm> ah ok, that explains it

[13:58:16] <cescoffier> It's a big change in the sonar strategy - but they have more control

[14:07:27] <wei_> AlexLehm, you are back?

[14:07:36] <AlexLehm> yes

[14:07:44] <wei_> Great.

[15:23:18] <wei_> AlexLehm, we found that it's due to subscriber in rabbitmq was not receiving messages in order. Thanks. :)

[15:23:31] <AlexLehm> ok great

[16:09:25] <AlexLehm> cescoffier: can I ask you about your comment to the mail-client pr?

[16:09:46] <AlexLehm> i am not sure if I understood the comment correctly, the headers variable does not set the other properties

[16:09:50] <cescoffier> AlexLehm : of course

[16:10:44] <cescoffier> from which PR are referring ?

[16:10:52] <AlexLehm>

[16:13:03] <cescoffier> thanks, so my point was that if someone had in its header the `contentId`, how does that work now ?

[16:14:19] <AlexLehm> that works as before, if the setContentId property is not set (since it didn't exist before), the header with “Content-ID”:“<id1 at example dot com>” will still be present in the mail text

[16:14:58] <cescoffier> ok, good, that was my question

[16:15:07] <cescoffier> so there is no “breaking change”

[16:15:13] <AlexLehm> yes

[16:15:16] <cescoffier> perfect !

[16:15:26] <AlexLehm> the feature was introduced in 3.3.0-snapshot anyway, it was not yet in 3.2.1

[16:16:02] <AlexLehm> ah, that is not completely correct, the inline image feature was introduced, the normal attachment could have done that before

[16:16:07] <AlexLehm> ok, but its not a breaking change

[16:16:18] <cescoffier> oh sorry…. didn't notice that (a bit too much change in 3.3.0 to follow all of them ;-))

[16:20:53] <AlexLehm> ok, with that, are you ok with the PR?

[16:23:53] <AlexLehm> or i should say, with the additional changes in the pr are you ok with merging the PR?

[16:32:30] <AlexLehm> temporalfox: i noticed that the jenkins build for vertx-core is broken for some time, which means that the snapshot is not updated I think

[16:32:37] <temporalfox> yes

[16:32:46] <temporalfox> somebody need to look at the failing tests :-)

[16:32:57] <temporalfox> thing is that cloudbees is much slower than a laptop

[16:33:06] <temporalfox> so it shows bugs that wouldn't happen on your system

[16:33:10] <temporalfox> (or mine)

[16:37:10] <temporalfox> that's why there is code freeze AlexLehm :-)

[16:37:15] <temporalfox> so now we spend time fixing these :)

[16:38:10] <AlexLehm> most of the tests are failing on windows for some reason, I haven't looked much on the tests that I didn't change

[16:38:15] <AlexLehm> i can take a look with virtualbox though

[16:39:42] <temporalfox> that would be nice

[16:39:47] <temporalfox> I don't have a windows

[16:41:30] <temporalfox> going to look at cloudbees problem

[16:41:43] <temporalfox> I hope it's reproduceable on my machine

[16:44:58] <temporalfox> I will look at

[16:44:58] <temporalfox> WebsocketTest.lambda$null$348:964→AsyncTestBase.assertTrue:372 null

[16:45:04] <temporalfox> the others I don't know why they fail

[17:03:32] <temporalfox> so the websocket expects a failrue

[17:03:36] <temporalfox> but not Caused by: Connection reset by peer

[17:04:01] <temporalfox> but I think other tests are also failing because of timemouts

[17:33:16] <AlexLehm> temporalfox: netty 4.1.0 final is out i just noticed, that should include one fix i did to make LOCALHOST resolve properly

[17:33:22] <temporalfox> yep

[17:33:25] <temporalfox> ok

[17:33:27] <temporalfox> good to know

[17:33:33] <temporalfox> I have a PR for it pending

[17:33:47] <temporalfox> as they changed apis since latest 4.1.0.CR7

[17:33:59] <temporalfox> trying to get the websocket test passing before :-)

[17:34:12] <AlexLehm> ok :-)

[17:35:49] <AlexLehm> you are probalby right about timeouts, the tests are taking very long on my local machine

[17:37:32] <temporalfox> anyway good work for the proxy!

[17:37:34] <temporalfox> again

[17:42:29] <AlexLehm> ok, i think you have fixed the test

[17:42:55] <temporalfox> yes

[17:43:01] <AlexLehm> the exectution of the build takes about 6 minutes on the jenkins and i am at 19 minutes already :-(

[17:43:02] <temporalfox> we will see if it happens regularly

[17:43:12] <temporalfox> for the tests ?

[17:43:14] <temporalfox> hum

[17:43:23] <AlexLehm> yes

[17:43:31] <temporalfox> can you try before the proxy ?

[17:43:42] <temporalfox> work we merged

[17:43:48] <temporalfox> I've done some changes to DNS lookup

[17:43:57] <temporalfox> and it was making tests very slow for me

[17:44:10] <temporalfox> so I had to do some patches

[17:44:13] <temporalfox> we may have to revert this

[17:45:43] <AlexLehm> i will let the tests run to the end once and then try an older version

[17:46:28] <temporalfox> AlexLehm just run the HttpTest

[17:46:30] <temporalfox> and compare

[17:46:33] <temporalfox> Http1xTest

[17:46:36] <temporalfox> or Http2Test

[17:46:44] <temporalfox> was it faster before ?

[17:59:03] <AlexLehm> it takes 41s for the Http1x test with the new version and 55s an older one

[17:59:48] <AlexLehm> it is faster now

[17:59:56] <temporalfox> ok

[18:00:07] <temporalfox> there is one bug in netty

[18:00:12] <temporalfox> I worked around

[18:00:28] <temporalfox> actually in non proxy client now we use the “AddressResolverGroup”

[18:00:36] <temporalfox> instead of the AsyncBindConnectResolverHelper

[18:00:48] <temporalfox> the benefit of the AddressResolverGroup is to reuse the same event loop

[18:01:03] <temporalfox> the current event loop

[18:01:12] <temporalfox> so it maintains a Map<EventLoop, AddressResolver>

[18:01:18] <temporalfox> and during shtudown

[18:01:27] <temporalfox> when an EL is shutdown the resolver is closed

[18:01:34] <temporalfox> however when this happens

[18:01:49] <temporalfox> the EL takes 1 second to shutdown because the network select()

[18:02:05] <temporalfox> does not return immediatly because the AddressResolver is still doing some network stuff

[18:02:14] <temporalfox> well actually it has some registration in the selector keys

[18:02:18] <temporalfox> so it's a deadlock

[18:02:24] <temporalfox> but there is a one second timeout

[18:02:42] <temporalfox> the solution is to close all the resolvers before shutting down the EL

[18:02:46] <temporalfox> (which is what is done now)

[18:08:36] <ch007m> Is there a verticle publishing a HTTP endpoint that we can use to fetch all the services published within the discovery service ?

[18:11:43] <AlexLehm> ok, when i take the running time reported by the tests, there is basically no difference, 31 or 32 seconds

[18:20:12] <temporalfox> ok

[18:20:57] <temporalfox> ch007m is it complex to deploy an HTTP endpoint ?

[18:21:33] <temporalfox> looks like Netty 4.1.0.Final changes something to HTTP CONNECT

[18:22:58] <ch007m> Not complex

[21:59:04] <AlexLehm> can I turn on the netty debug log in vertx somehow?