Differences

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

Link to this comparison view

irc:1453158000 [2017/05/27 13:44]
 irc:1453158000 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[01:51:19] *** ChanServ sets mode: +o temporalfox
 +
 +[01:59:49] <theRealGent> since vert.x uses hazelcast for clustering, do I get access to any of the distributed data structures like a Map from hazelcast?
 +
 +[02:31:00] <theRealGent> It would be really nice if vert.x exposed the EntryProcessor feature of Hazelcast. I'm looking at AsyncMap and can't figure out a way to do an atomic operation like "if empty, place 0, if not, increment by 1."
 +
 +[02:31:22] <theRealGent> Like a java 8 map merge.
 +
 +[10:29:36] <Narigo> Something broke over night with mysql-postgresql :( I get a "NoSuchMethodError" on io.vertx.core.Future.setHandler in my tests now...
 +
 +[10:30:29] *** ChanServ sets mode: +o temporal_
 +
 +[10:31:47] <Narigo> Guess I shouldn't rely on SNAPSHOT versions - temporalfox, cescoffier, can we decide on this issue and release? https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/25
 +
 +[10:32:13] <Narigo> ...or temporal_ ?
 +
 +[10:32:46] <temporal_> I'm there twice ?
 +
 +[10:32:52] <temporal_> ah yes
 +
 +[10:32:54] <temporal_> VPN
 +
 +[10:33:00] <cescoffier> Yes Julien, you are here twice, happened to me last week
 +
 +[10:33:00] <temporal_> and wifi
 +
 +[10:33:02] <temporal_> combined
 +
 +[10:33:07] <temporal_> not the smae IP
 +
 +[10:33:29] <temporal_> one is gone
 +
 +[10:34:03] <Narigo> Oh no! One less to help with my issue...! ;)
 +
 +[10:34:04] <cescoffier> @Narigo, are you implementing Future ?
 +
 +[10:34:48] <cescoffier> (it does  not look like you are)
 +
 +[10:35:36] <Narigo> cescoffier, we use Scala in our product that we build and have our own VertxExecutionContext there that uses it. Our only SNAPSHOT dependency is mysql-postgresql and I guess through some dependency magic in all those pom files something breaks ;)
 +
 +[10:36:05] *** ChanServ sets mode: +o temporalfox
 +
 +[10:37:10] <cescoffier> We added methods on Future to improve composability. However except if you have your own implementation of Future it should be compatible
 +
 +[10:37:31] <temporalfox> Narigo what is breaking for you ?
 +
 +[10:38:08] <Narigo> Yesterday everything was okay, today at 2 am when I tried to fix a bug in the night, it downloaded stuff (like every day with a SNAPSHOT dependencies) and then I got: java.lang.NoSuchMethodError: io.vertx.core.Future.setHandler(Lio/vertx/core/Handler;)Lio/vertx/core/Future;
 +
 +[10:38:09] <cescoffier> "Something broke over night with mysql-postgresql 😞 I get a "NoSuchMethodError" on io.vertx.core.Future.setHandler in my tests now..."
 +
 +[10:41:21] <cescoffier> Narigo : which test is failing
 +
 +[10:41:26] <Narigo> https://gist.github.com/Narigo/a6272db5bc4f045823a0 <- here is the stacktrace if that helps anything... In IntelliJ everything is fine ;)
 +
 +[10:41:28] <temporalfox> but this happen in mysql posgtgres ?
 +
 +[10:41:47] <temporalfox> perhaps that you have some snapshot desync ?
 +
 +[10:42:07] <temporalfox> because it tries to find a method with Future
 +
 +[10:42:15] <Narigo> cescoffier, all tests that rely on mysql-postgresql-client in my project - not mysql-postgresql itself
 +
 +[10:42:17] <temporalfox> and this Future replaces now "void"
 +
 +[10:42:23] <temporalfox> and at runtime it does not find it
 +
 +[10:43:14] <cescoffier> could you post the code of io.vertx.ext.asyncsql.impl.AsyncSQLConnectionImpl.setAutoCommit
 +
 +[10:44:28] <Narigo> cescoffier, https://github.com/vert-x3/vertx-mysql-postgresql-client/blob/master/src/main/java/io/vertx/ext/asyncsql/impl/AsyncSQLConnectionImpl.java#L70-L87
 +
 +[10:44:34] <cescoffier> found it....
 +
 +[10:45:07] <Narigo> temporalfox, I'm not sure what you mean by snapshot desync.. I tried removing ~/.gradle/caches/ - it re-downloaded everything and same error
 +
 +[10:45:54] <temporalfox> so what do you have in your jar ?
 +
 +[10:45:57] <cescoffier> it should work, the API didn't change here
 +
 +[10:46:01] <temporalfox> can you do javap on this ?
 +
 +[10:46:07] <temporalfox> on Future
 +
 +[10:47:48] <Narigo> umm... now I just need to google how to do that with IntelliJ / Gradle :S
 +
 +[10:55:33] <Narigo> temporalfox, https://gist.github.com/Narigo/a6272db5bc4f045823a0#file-javap-on-future-txt
 +
 +[10:55:59] <temporalfox> it looks like you don't have the good jar
 +
 +[10:56:05] <temporalfox> it says void
 +
 +[10:56:28] <temporalfox> but your mysql driver seems to use the good one
 +
 +[10:56:48] <cescoffier> the good one is the "new" one
 +
 +[10:56:58] <Narigo> That looks like...?
 +
 +[10:57:14] <Narigo> And where / how can I get it? :)
 +
 +[10:57:36] <Narigo> Do I need to use a Vert.x 3.3.0-SNAPSHOT version now, too? :S
 +
 +[10:58:08] <temporalfox> but you are using mysql postgres 3.3.0 SNPASHOT ?
 +
 +[11:00:15] <Narigo> yes :/ as there is no real release :(
 +
 +[11:03:59] <amack2> Hi, I want to use the Launcher with a fatjar, but my Command is not found. I've extended DefaultCommand and have overriden "run()". The help of the fat jar doesn't list it
 +
 +[11:08:53] <cescoffier> amack2 how did you declare your command ?
 +
 +[11:09:01] <amack2> fatjar with running a Main-Verticle works
 +
 +[11:09:13] <cescoffier> amack2 : do you have the command factory and the service file filed ?
 +
 +[11:09:14] <amack2> cescoffier: using annotations
 +
 +[11:09:27] <cescoffier> it's not enough, you need a second class (factory)
 +
 +[11:09:33] <cescoffier> let me show you an example
 +
 +[11:09:39] <amack2> cescoffier: cool, thanks
 +
 +[11:10:09] <cescoffier> amack2 : for example, here you have a command: https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/impl/launcher/commands/StartCommand.java
 +
 +[11:10:24] <cescoffier> amack2 : but also a factory: https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/impl/launcher/commands/StartCommandFactory.java
 +
 +[11:10:43] <cescoffier> amack2 : when using annotaiton the factories are always more or less the same
 +
 +[11:11:07] <cescoffier> amack2 : then the command factory class must be added in https://github.com/eclipse/vert.x/blob/master/src/main/resources/META-INF/services/io.vertx.core.spi.launcher.CommandFactory
 +
 +[11:11:39] <cescoffier> amack2 : in your src/main/resources/META-INF/services/io.vertx.core.spi.launcher.CommandFactory. The name is very important
 +
 +[11:12:31] <Narigo> temporalfox, cescoffier, so I tested with 3.3.0-SNAPSHOT now: It would work now. The problem is that I really don't want to depend on SNAPSHOT releases at all. Can we release a 3.2.0 version of mysql-postgresql? :/ Even with the issue mentioned before? I'm not sure what the resolution to it is
 +
 +[11:12:46] <amack2> I see, thanks a lot. I think a short paragraph on the Core doc page "The vert.x Launcher" would help
 +
 +[11:12:59] <cescoffier> amack2 : will write that right now
 +
 +[11:14:36] <temporalfox> Narigo I don't understand what you have been using so far
 +
 +[11:14:45] <temporalfox> 3.2.0-SNAPSHOT ?
 +
 +[11:15:27] <cescoffier> temporalfox : he is using vert.x core 3.2.0, but vert.x mysql async driver 3.3.0-SNAPSHOT
 +
 +[11:15:37] <Narigo> temporalfox, there is no mysql-postgresql-client release AFAIK so we've used 3.3.0-SNAPSHOT right now.
 +
 +[11:15:44] <Narigo> correct
 +
 +[11:15:45] <temporalfox> ah ok
 +
 +[11:15:49] <temporalfox> so two different dependnecies
 +
 +[11:16:19] <Narigo> and 3.2.0-SNAPSHOT wouldn't work as the vertx 3.2.0-SNAPSHOTs are not there anymore / were deleted...
 +
 +[11:16:24] <temporalfox> doing a 3.2 release called "tech preview" seems doable
 +
 +[11:17:48] <Narigo> Can we get a resolution to the mentioned issue as well? I mean this is really the only blocking thing I guess? https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/25
 +
 +[11:18:17] <temporalfox> I will let Paulo / Clement comment on it :-)
 +
 +[11:18:39] <cescoffier> it's more Paulo
 +
 +[11:18:51] <Narigo> Maybe this is related to it: https://github.com/vert-x3/vertx-sql-common/issues/4
 +
 +[11:18:51] <cescoffier> do we do a 3.2.0 release or wait to be in 3.2.1 ?
 +
 +[11:19:06] <Narigo> cescoffier, as fast as possible please :D
 +
 +[11:19:16] <Narigo> So I'd vote for 3.2.0
 +
 +[11:19:17] <cescoffier> 3.2.1 is due very very soon
 +
 +[11:19:22] <Narigo> today? :)
 +
 +[11:19:25] <temporalfox> no
 +
 +[11:19:31] <temporalfox> couple of weeks max
 +
 +[11:19:50] <temporalfox> I can deploy a 3.2.0 jar to central
 +
 +[11:20:00] <temporalfox> if you give me a green light
 +
 +[11:20:11] <temporalfox> (I mean any one)
 +
 +[11:22:50] <Narigo> Here: <green light>
 +
 +[11:22:54] <Narigo> :)
 +
 +[11:23:16] <temporalfox> there is this issue mentionned though
 +
 +[11:23:32] <temporalfox> Narigo have you tested this driver against the JDBC blocking driver ?
 +
 +[11:23:57] <temporalfox> Narigo we're interested to know about the scalability / perf difference if you have some to give us
 +
 +[11:24:35] <temporalfox> throughput ,etc...
 +
 +[11:24:37] <Narigo> temporalfox, no, I didn't do any benchmarking on it
 +
 +[11:25:02] <Narigo> Well, it's fast enough for us right now... ;)
 +
 +[11:25:12] <temporalfox> Narigo pretty sure it is
 +
 +[11:25:34] <temporalfox> how many connections to the database ?
 +
 +[11:26:38] <Narigo> temporalfox, not using more than 5 right now but it's really not a hardcore concurrent app, so I don't think you will get any good numbers from me here :/
 +
 +[11:26:54] <temporalfox> ok
 +
 +[11:27:04] <temporalfox> so blocking client would work well too for you :-)
 +
 +[11:29:15] <cescoffier> temporalfox Narigo : I would wait Paulo green light regarding the pending issue. It's a tricky one making the MYSQL/PostGRes driver not a "drop-in" replacement of the jdbc-client
 +
 +[11:29:16] <Narigo> temporalfox, we can't replace one client with the other.. there was some issue with the blocking driver :/
 +
 +[11:29:35] <cescoffier> temporalfox Narigo : At least it requires some sentences in the documentation
 +
 +[11:29:43] <cescoffier> (and explanation about the why)
 +
 +[11:33:02] <Narigo> temporalfox, we could add a benchmark test to both SQL clients...?
 +
 +[11:33:32] <Narigo> Like "Do some queries 10000 times"...?
 +
 +[11:48:33] <Narigo> cescoffier, temporalfox, so what can we do about the release now? Can I do something to accelerate it? ;)
 +
 +[11:48:53] <temporalfox> I need greenlight from paulo
 +
 +[11:52:26] <Narigo> When will he be here? Isn't his greenlight needed only to find a resolution for the pending issue? Do we have to wait for it when releasing a "-tech-preview" ?
 +
 +[12:16:59] <cescoffier> Narigo, even for technical preview, we need to be sure it's in a stable state
 +
 +[12:17:20] <cescoffier> Paulo has opened this issue, we would like to know if he agree to do a release without a fix for this one
 +
 +[12:17:44] <cescoffier> if he considers the issue as blocking, then we would need to fix it somehow before cutting a release
 +
 +[12:20:05] <Narigo> Hmm... we're using it currently. And if he considers the issue as blocking, I'm unsure if the changes that would need to be done are correct to do in the vertx wrapper itself. I guess it'd be the responsibility of the driver then
 +
 +[12:26:20] <Narigo> And PostgreSQL itself lets the user decide whether or not to return auto incremented ids through the "RETURNING" command... :/ I'm really not sure if a "drop-in-replacement" is a good idea. You can't drop-in-replace different SQL drivers in JDBC when using specific features/SQL of a database, so why is this a requirement here? :/
 +
 +[13:53:22] <polyurethan> It's the jdbc postgresql driver which is doing it wrong. (IMHO)
 +
 +[13:55:15] <polyurethan> And regarding the sql-common interface it's not ideal because of the mentioned problem with "RETURNING" multiple columns. (see https://github.com/vert-x3/vertx-sql-common/issues/4)
 +
 +[14:56:04] <polyurethan> cescoffier, temporalfox, any comment on my last two messages?
 +
 +[15:10:02] <Narigo> Behold, the mighty pmlopes has arrived! We are eager to hear your opinion about a 3.2.0 release of the async mysql-postgresql-client!
 +
 +[15:10:48] <pmlopes> good afternoon to you too :)
 +
 +[15:11:12] <Narigo> cescoffier, temporalfox do you see the green light? I see it! It's near! :)
 +
 +[15:44:15] <temporalfox> Narigo  you can understand that before doing a public release in maven central that other people than you consume, we want to ensure a few things even if it's a tech preview
 +
 +[15:49:04] <Narigo> Well, it's a named SNAPSHOT that doesn't break at some point due to SNAPSHOT dependencies... ;)
 +
 +[16:06:19] <pmlopes> @Narigo i've a PR open for support of generated ids on postgres, however it does not return for mysql since mysql does not support the returning keyword. Also this client does not support stored procedures, if we make a release we cannot say that it is a drop-in replacement for jdbc client.
 +
 +[16:06:37] <cescoffier> that's an annoying point
 +
 +[16:06:52] <cescoffier> it implements the same interfaces, but with holes
 +
 +[16:07:31] <Narigo> pmlopes, do you really think it the wrapper is the right place to change user statements for the RETURNING stuff?
 +
 +[16:08:37] <Narigo> MySQL could return the last inserted id (from the driver) IIRC
 +
 +[16:08:38] <pmlopes> that is how the jdbc works, if the behavior is different then we cannot claim that it is a dropin replacement
 +
 +[16:09:12] <Narigo> Is a MySQL driver a drop-in replacement for PostgreSQL driver in JDBC? :/
 +
 +[16:09:41] <polyurethan> But who wants to claim that it is a drop-in replacement?
 +
 +[16:10:00] <temporalfox> I think it is a drop il replacement because it implements the same api / interface
 +
 +[16:10:09] <temporalfox> the SqlConnection right ?
 +
 +[16:10:12] <temporalfox> SQLConnection
 +
 +[16:10:54] <polyurethan> I don't see the need for that. The postgresql jdbc driver made a bad decision years ago which can't be undone [unknown:ndash] bad for them.
 +
 +[16:10:55] <pmlopes> no, mysql is no drop-in replacement for postges but the official driver from postgres and the non official one from mauricio should be since they talk to the same DBMS and use the same under lying API (java.sql) since the contract is the same one would expect the same behavior
 +
 +[16:10:57] <pmlopes> right?
 +
 +[16:11:14] <polyurethan> No.
 +
 +[16:11:36] <polyurethan> the postgresql jdbc driver changes the statement and thats bonkers...
 +
 +[16:11:44] <pmlopes> @polyurethan the contract of returning generated keys is defined in the java.sql.Statement not on the driver
 +
 +[16:12:04] <Narigo> pmlopes, Mauricios driver is completely different and we map the JDBC API around it :(
 +
 +[16:12:45] <polyurethan> ok, but jdbc is not a great api example. and sql-common could be a better one.
 +
 +[16:13:19] <polyurethan> and so you force jdbc api specific thing up on the sql-common api
 +
 +[16:14:00] <pmlopes> this problem was not raised by me, our users have reported it: https://github.com/vert-x/mod-mysql-postgresql/issues/52
 +
 +[16:18:01] <Narigo> pmlopes, for MySQL we could return an ID as the driver should support it. PostgreSQL did this "hack the users statements" in their driver to support the JDBC API. A user of PostgreSQL also has the option to insert "RETURNING" statements when needed
 +
 +[16:18:27] <pmlopes> i don't force JDBC but the sql common was modeled around it. When used with the standard drivers (mysql, postgres, oracle you name it) its behavior is consistent, one could say lets create a module with the async driver (and that is fine) however we must tell the users that don't expect the same behavior, although the contract (interface) is the same there no returning of generated keys, there is no stored procedure support, date time pre
 +
 +[16:18:29] <pmlopes> cission is different from mysql to postgres... if all this things are properly documented so no bug reports are raised about it it should be fine
 +
 +[16:21:57] <Narigo> pmlopes, so when we add documentation about the change of last inserted ids, everything is good to go?
 +
 +[16:22:39] <cescoffier> well the stored procedure support need to also be documented
 +
 +[16:23:46] <Narigo> I guess we need to check what's working and what's not working wrt stored procedures...
 +
 +[16:25:45] <Narigo> pmlopes, is it okay for you, if I don't merge your PR? (It's missing tests anyways ;))
 +
 +[16:27:16] <pmlopes> sure. I was just trying to see what i could do in the end you're the owner, you've the final call :)
 +
 +[16:28:49] <Narigo> Not regarding the releases obviously ;) But okay, I'll try to document everything and show the "workarounds" for the ids
 +
 +[16:37:32] <pmlopes> going over the open issues I think you should give a look at https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/10 i don't know the details but the report says that he gets wrong results from queries...
 +
 +[16:39:10] <polyurethan> Glad to see there will be some progress (hopefully) regarding the mysql-postgresql-client!
 +
 +[16:39:31] <Narigo> pmlopes, that was before the whole port to Java and I suspect this won't happen anymore. The problem is that we don't really have a test for this now :/
 +
 +[16:39:38] <Narigo> ..or reproducer
 +
 +[16:41:24] <polyurethan> pmlopes Is it possible to talk about this issue? https://github.com/vert-x3/vertx-sql-common/issues/4
 +
 +[16:41:39] <pmlopes> sure
 +
 +[16:45:22] <polyurethan> pmlopes Do you think it's possible to extend the type UpdateResult to support returning multiple columns?
 +
 +[16:46:19] <polyurethan> pmlopes It doesn't seem right to use query() for this.
 +
 +[16:51:05] <polyurethan> pmlopes If there are generated values in a statement, someone could only get the first of these generated values.
 +
 +[16:51:10] <pmlopes> UpdateResult contains an array of values
 +
 +[16:52:25] <pmlopes> but changing sql-common interfaces will likely break APIs and for than we need to wait for a 3.3 release if the breakage is small for 3.2.1 we only accept bug fixes and no api breaks
 +
 +[16:54:23] <polyurethan> pmlopes An array of values, but only one value foreach row. Try to imagine this statement: UPDATE example SET foo = TRUE, bar = NOW() RETURNING id, bar;
 +
 +[16:55:06] <polyurethan> pmlopes Wouldn't work right now with the current UpdateResult.
 +
 +[16:55:39] <pmlopes> then it UpdateResult should be something like {updates: 2, keys : [idValue, barValue]}
 +
 +[16:55:52] <Narigo> Quick question about documentation: Can I use <a href="...">some link</a> in the package-info.java to link to some external site? (I want to point to the PostgreSQL documentation about the RETURNING clause)
 +
 +[16:56:31] <polyurethan> pmlopes but the update would change not only one row (should have mentioned that)
 +
 +[16:57:26] <polyurethan> pmlopes so that only works for one row. also it's possible to add multiple rows with one insert statement which also could return multiple columns per row.
 +
 +[16:58:59] <pmlopes> yes you can use links asciidoc allows it, for multiple rows then you need to use the query response, it would be the same if you would be using jdbc
 +
 +[17:16:03] <polyurethan> pmlopes again, jdbc is not a good example to build a new api
 +
 +[19:19:30] <Narigo> Here's something to review temporalfox or cescoffier: https://github.com/vert-x3/vertx-mysql-postgresql-client/pull/31 :) Hope that's good enough for a 3.2.0 release then?
 +
 +[20:20:56] <pmlopes> @Narigo I think your PR is good and documents that the async client is not a drop in replacement for jdbc client, i shall give you the green light :) as you've asked :)
 +
 +[20:23:44] <temporalfox> cool, I think we can make a 3.2.0 release
 +
 +[20:41:19] <xkr47> hi
 +
 +[20:42:19] <xkr47> is there any vertx api for java.nio.file.WatchService ?
 +
 +[20:43:27] <xkr47> ah.. Just had to look for references to WatchService in eclipse with vertx modules in classpath :)
 +
 +[20:46:25] <xkr47> but it's inside an impl package - is it meant to be used ?
 +
 +[20:47:14] <xkr47> apparently not :P
 +
 +[22:23:27] *** ChanServ sets mode: +o temporal_