[08:55:55] <cescoffier> purplefox temporalfox pmlopes - we have a corruption on the snapshot repository. A docgen build has failed to upload the right metadata. So the stored sha1 is not correct. It may breaks all build depending on docgen as Maven does not like such kind of issue. I'm investigating, and let you know.
[08:56:18] <cescoffier> for local build, if you see the issue, build docgen locally
[08:56:27] <pmlopes> ok, thanks
[09:01:57] <cescoffier> purplefox temporalfox pmlopes - it's fixed.
[10:22:19] <aesteve> hello everyone :)
[10:50:36] <cescoffier> hello aesteve
[11:09:43] <prakash> hello
[11:09:51] <prakash> anyone theere
[11:23:09] <aesteve> hi prakash
[11:25:20] <prakash> hey aesteve
[11:25:55] <prakash> have anyone of you tried mixing vertx2 modules and vertx3 services/modules
[11:26:43] <aesteve> sorry, no :( I've migrated everything to use vertx3 clients and get rid of the event-bus communication between modules
[11:27:04] <prakash> aah too bad :(
[11:27:36] <prakash> do you have any idea how can i run long running jdbc stored proc using vert.x 2
[11:27:48] <prakash> i was planning on using rxjava
[11:27:58] <prakash> do you have any better solutions to that
[11:28:28] <aesteve> I'm far from being a vertx2 expert unfortunately, sry I'm not of any help here
[11:29:01] <prakash> aah thanks for you input though
[11:32:05] <aesteve> do you have a huge existing code base in Vert.x 2 ?
[11:33:27] <prakash> let's say about 6 medium sized modules
[11:33:50] <aesteve> ah ok.
[11:34:22] <prakash> i'd migrate them to 3 but i cannot figure out the new service system in vertx 3
[11:34:54] <aesteve> they're simply classes you instanciate and just work with
[11:34:59] <aesteve> https://github.com/vert-x3/vertx-jdbc-client/
[11:35:33] <aesteve> there's no “module”, it's a simple jar you add as a dependency
[11:35:59] <prakash> an configurigation to run them ??
[11:36:02] <prakash> programtic ??
[11:36:13] <prakash> programatic
[11:36:45] <prakash> i mean worker and cluster config ??
[11:41:05] <basky> hi guys
[11:41:18] <basky> anyone using vertx 3 ?
[11:44:47] <cescoffier> basky - yes, we can probably say that
[11:45:25] <basky> cescoffier - i am struggling with clustering on vertx 3
[11:45:56] <pmlopes> ok, i am on the redis bugs
[11:46:02] <cescoffier> basky - what kind of issue do you have ?
[11:46:22] <basky> cescoffier - whenever i try using -ha i get this Exception in thread “main” java.lang.IllegalStateException: No ClusterManagerFactory instances found on classpath
[11:46:54] <cescoffier> basky are you launching your applicaiton using `vertx run …` or as a fat jar ?
[11:46:59] <basky> cescoffier - I have all the libs in my classpath still it cannot locate the class
[11:47:16] <basky> cescoffier - as fatjar
[11:47:34] <cescoffier> basky - are you building your fatjar using Maven ?
[11:48:58] <basky> cescoffier - I am using gradle .. what I am trying to achieve is to cluster eventbuses from vertx 2 and 3 .. experimented on that ??
[11:49:19] <cescoffier> basky - unfortunately not
[11:49:33] <cescoffier> basky - however check that the fat jar contain the hazelcat jars
[11:49:38] <purplefox> basky: you need to add a cluster manager to your classpath, e.g. vertx-hazelcast
[11:50:03] <purplefox> basky: http://vert-x3.github.io/docs/vertx-hazelcast/
[11:50:23] <purplefox> there's also an example in the vertx-examples repo
[11:51:20] <cescoffier> basky - if you look at this pom file (https://github.com/vert-x3/vertx-examples/blob/master/maven-verticle/pom.xml), you see two dependencies required to get clustering working. Add them to your gradle build and package them in your fat jar. Then, if should find the cluster manager factory
[11:52:09] <cescoffier> purplefox - the gradle example does not declare the hazelcast dependencies….
[11:52:54] <cescoffier> purplefox - will have a look (should be equivalent to the maven verticle example)
[11:52:55] <basky> purplefox cescoffier - I have added the jars manually. will try adding it to dependencies on gradle .. Thanx guys .. also do u guys think event buses on vertx 3 and 3 communicate with clustering ?
[11:53:23] <basky> sorry vertx 2 and 3
[11:53:59] <purplefox> basky: the clustered event bus examples are here https://github.com/vert-x3/vertx-examples/tree/master/core-examples/src/main/java/io/vertx/example/core/eventbus
[11:54:15] <purplefox> basky: the docs (linked above) should explain exactly what deps you need and how to add them
[11:55:33] <basky> purplefox - will try playing with them and experimenting with event buses on 2 and 3 .. thanx guys
[11:58:38] <purplefox> basky: eventbuses 2 and 3 are not compatible
[12:01:39] <basky> purplefox - we do have a big application on vertx 2. We are trying to implement stored proc execution on it, but available modules dont support proc exec. Any suggestions for stored proc exec on vertx 2. We cant migrate the whole application right away to vertx 3
[12:03:22] <basky> purplefox- we are using com.bloidonia~mod-jdbc-persistor~2.1.3 module for sql operations but it dosent have stored proc support. Does this mean we need to write a wrapper
[12:34:13] <pmlopes> purplefox: redis bug is squashed! PR ready for review
[19:55:09] <voidDotClass> I have a simple server which just sends a hello world string to http requests, but I'm seeing a time to first byte of 400 ms - 900 ms with vertx. why does it take so long?
[19:56:56] <voidDotClass> just network?
[21:46:42] <whoisjake> so I have a fat jar… I'm using vertx run and loading the verticle properly out of the fat far… but when I add a -cluster, it vomits: https://gist.github.com/whoisjake/e88c6b8f925b5163ac4f
[21:47:03] <whoisjake> SO far, everything in the stack trace is internal… and it looks to be starting the Hazelcast stuff
[21:47:16] <whoisjake> it looks like some reflection issues, not sure it's anything on my side
[21:47:42] <whoisjake> the project POM files are using the 3.0.0-SNAPSHOT from Sonatype Nexus Snapshots
[21:49:20] <whoisjake> going to try a reproduction in the example project
[21:55:23] <whoisjake> ok, so using java -jar … works… using vertx run, does not
[21:55:35] <whoisjake> wonder if it's because -cp needs to have the vertx/lib directory in there?
[21:56:56] <whoisjake> I wonder if the gap is between my vertx downloaded as milestone 6 vs. the fat jar having 3.0.0-SNAPSHOT code
[21:59:36] <whoisjake> and so invoking the jar with the downloaded vertx binary is causing the wonkiness of invalid state with reflection… as if the reflection bits are slightly different between them
[22:25:48] <AlexLehm> whoisjake, the logging classes were moved about 2 days ago or so, so you probably have a logging class that doesn't fit the one from m6, which had the old logging class package
[22:26:03] <AlexLehm> either building everything with m6 or with the current snapshot should be ok
[22:26:13] <whoisjake> ahh I see
[22:26:48] <whoisjake> thank you
[22:26:53] <whoisjake> I'll give that a shot and report back
[22:34:58] <whoisjake> now a whole other exception… https://gist.github.com/whoisjake/093ea73e07d590fe5cb5
[22:35:41] <whoisjake> and another thing I should note, I was able to run the cluster examples from the vert-x3/vertx-examples … using the same method, so I must be doing *something* wrong
[22:35:43] <whoisjake> :: shrugs ::
[22:38:00] <AlexLehm> about Hazelcast I have absolutely no idea
[22:42:28] <whoisjake> thank you for your help
[22:43:41] <whoisjake> is there a way with vertx to specify starting up a certain verticle within the fat jar? instead of just the main startup one?
[22:43:43] <whoisjake> like
[22:44:11] <whoisjake> java -jar path/to/fat.jar com.mydomain.MyVerticle -cluster
[22:44:17] <whoisjake> that would solve all of my problems I think
[22:47:42] <AlexLehm> i think the verticle to start is in the manifest
[22:48:39] <AlexLehm> https://github.com/vert-x3/vertx-examples/blob/master/maven-verticle/pom.xml#L14
[22:48:58] <whoisjake> right… that assumes you only have one verticle per jar… or one main verticle in the jar that launches your configured set of others
[22:50:12] <AlexLehm> yes, i don't think there is an option to start another verticle with the same fatjar
[22:50:55] <whoisjake> I guess the alternative is to use a configuration file, have a “main verticle” that launches X number of instances of a verticle in the same jar programmatically…
[22:51:03] <whoisjake> thanks for your insight again, appreciate it