Differences

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

Link to this comparison view

irc:1464300000 [2017/05/27 13:44] (current)
Line 1: Line 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>​ https://​github.com/​vert-x3/​vertx-mail-client/​pull/​71
 +
 +[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: java.io.IOException:​ 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?