Approvals: 0/1
[11:02:04] <aesteve> hi everyone :)
[11:12:42] <temporal_> aesteve hi Arnaud
[11:13:03] <temporal_> the future stuff is merged in master, have you had chance to give a look ?
[11:13:14] <temporal_> I mean besides the feedback you did few days ago
[11:17:08] <aesteve> no I didn't have a look, sorry
[11:18:05] <aesteve> I have to first think about how to wrap it into my “batch executor” thingy
[11:18:19] <aesteve> not wrap it, use it, actually
[11:18:51] <aesteve> I have a question about vertx-unit though if you have a minute
[11:40:06] <temporal_> yes
[11:40:14] <temporal_> aesteve yes
[12:03:08] <aesteve> sorry, I was away for a sec
[12:03:19] <aesteve> the question is re. exception handling
[12:04:21] <aesteve> let's say you want to test eventbus sockjs bridge or smth like that
[12:04:51] <aesteve> you'll send a msg over the eventbus, and your test will be ws.handler { /* checkMsg */ async.complete() }
[12:05:43] <aesteve> if context.fail() is called within checkMsg, no problem at all, test is failing, etc.
[12:06:42] <aesteve> if an exception occurs during checkMsg… async.complete() is obviously not called, but… If you receive another message then you're screwed
[12:06:54] <aesteve> your test can pass then, and the first exception was swalloed
[12:09:28] <aesteve> so I was wondering, if there was any way to deal with that issue temporal_
[12:10:06] <aesteve> basically saying : “if an exception occurs within any callback, that's not normal, the test should stop immediately”
[12:10:39] <temporal_> ah you mean you fail after the test complete ?
[12:10:46] <temporal_> it fails after you called complete()
[12:12:58] <aesteve> that's not what I saw, I'll try to push a reproducer
[12:13:30] <temporal_> ok that would be cool
[12:13:54] <temporal_> ahhhhhh
[12:14:00] <temporal_> I see what you mean
[12:14:12] <temporal_> like an error that is happening on the event loop
[12:14:15] <temporal_> yeah…
[12:14:22] <temporal_> that's identified
[12:14:22] <aesteve> exactly
[12:14:40] <temporal_> I've done an issue in vertx core https://github.com/eclipse/vert.x/issues/1216
[12:14:41] <aesteve> do you have an issue # I can track ?
[12:14:47] <aesteve> you're reading my mind
[12:14:52] <temporal_> to have a way to be aware of what is happening in event loop
[12:15:10] <temporal_> so this could be used in tests to know errors thrown by event loop
[12:15:12] <temporal_> (or context)
[12:15:27] <temporal_> and basically it would also allow to avoid to have a TestContext
[12:15:35] <temporal_> passed
[12:16:03] <temporal_> that's an improvmeent I would like for 3.3 maybe
[12:16:13] <temporal_> it would be a good win
[12:16:16] <temporal_> in usability
[12:16:27] <aesteve> absolutely
[12:16:55] <aesteve> in fact it happened to a coworker and I understood why it was happening, but not how to explain it to him
[12:17:00] <temporal_> so idea is to have something to allow that
[12:17:03] <temporal_> and have this the simplest possible in core
[12:17:42] <temporal_> and it would allow to use junit assertions
[12:17:44] <temporal_> I htink
[12:17:54] <temporal_> because those just throw assertion errors
[12:18:07] <aesteve> idd
[12:18:07] <temporal_> so they would be reported
[12:18:14] <temporal_> and the test fails
[12:18:32] <aesteve> careful with the stacktrace though, but I don't think we would lose info
[12:18:39] <temporal_> no we would not
[12:19:58] <aesteve> thanks for the pointer Julien !
[12:24:18] <temporal_> you're welcome
[12:57:46] * ChanServ sets mode: +o temporalfox
[14:40:46] <vertxfan> if I run multiple instances of a verticle, should I expect them to run concurrently ?
[14:41:02] <vertxfan> I mean, do I need to synchronize access to class variables in the verticle code ?
[14:41:56] <vertxfan> (I use DeploymentOptions.setInstances() to define the number of instances)
[14:45:31] <temporalfox> vertxfan no, by default you don't need synchronization at all
[14:45:47] <temporalfox> what do you mean by class variables actually ?
[14:45:58] <temporalfox> you mean non static right ?
[14:46:12] <aesteve> mmh “class variable”
[14:46:18] <vertxfan> yes, non static
[14:46:29] <aesteve> so : instance variable
[14:46:31] <vertxfan> yes
[14:46:39] <temporalfox> it is fine then, you will have X instances and each instance will always use the same thread
[14:46:43] <aesteve> no synchronize required indeed
[14:47:09] <vertxfan> got it, thanks
[14:47:16] <aesteve> put a log or println within your contructor, you'll see what happens ;)
[15:41:07] <voidDotClass> When I do the query: SELECT * from foo WHERE (name ILIKE 'foo%') ORDER BY name ASC LIMIT 10 OFFSET 0, that returns 10 results, one of which has the id: 52
[15:41:17] <voidDotClass> oops, wrong channel
[15:41:52] <aesteve> temporalfox: did you have a look at : http://shipilev.net/blog/2016/arrays-wisdom-ancients/ ?
[15:42:34] <temporalfox> no, what is it ?
[15:48:15] <Ladicek> one of the more approachable Shipilev's articles on dark corners of JVM performance
[15:48:31] <aesteve> looks like a benchmark on the Collection.toArray() method (which seems widely used in https://github.com/eclipse/vert.x/search?utf8=%E2%9C%93&q=toArray )
[15:56:49] <temporalfox>
[15:57:02] <temporalfox> we haven't yet optimized fully vert.x yet it is already very fast!
[15:57:17] <mweb> hi, I'm ugrading to vert.x v3.2.0 and I try to make a unit test using the @RunWith(VertxUnitRunner.class) annotation. The test is successfull but logs some suspicious warnings like “You're already on a Vert.x context, are you sure you want to create a new Vertx instance?”. How can I fix this warning? Thanks
[16:01:28] <temporalfox> I don't remember where this warning is coming from
[16:02:30] <mweb> it's from the VertxImpl constructor
[16:02:57] <mweb> it occurs when Vertx.currentContext() is not null
[16:03:46] <aesteve> temporalfox: yes but it sounds like an optimization for free, no ?
[16:04:05] <temporalfox> yes clearly you should not do that
[16:04:18] <temporalfox> how is your test looking like ?
[16:04:27] <temporalfox> aesteve yes I agree
[16:04:43] <temporalfox> it would be good that sometones spends time write some micro benchmarking we can execute
[16:04:59] <mweb> can i post code here directly?
[16:06:27] <mweb> @RunWith(VertxUnitRunner.class) public class NoClusterMembersOneVerticleInstancesTests { with this number we simulate the different member count of a cluster private final static int SIMULATED_CLUSTER_MEMBERS = 1; private Vertx vertx; private Logger log = LoggerFactory.getLogger(NoClusterMembersOneVerticleInstancesTests.class); private List<String> answers = new ArrayList<>(); @Before public void befor
[16:06:47] <mweb> that did not work as expected
[16:09:04] <temporalfox> make a gist please
[16:09:45] <mweb> yes I have to commit first
[16:17:22] <mweb> ok, my test class looks like this: https://gist.github.com/mcweba/e78c62edffadb45d1c21
[16:17:55] <mweb> here the link to the git repo https://github.com/mcweba/vertx-cluster-watchdog
[16:21:32] <aesteve> temporalfox: Tim pointed me at http://openjdk.java.net/projects/code-tools/jmh/ for micro-benchmarking one day
[16:21:49] <temporalfox> yes it is the trendy thing for microbench
[16:23:50] <aesteve> maybe you should create a repo under the vert.x organization with the basic mvn structure and a single (simple) benchmark within
[16:24:15] <aesteve> then make an announcement on the User group and people will start submitting PRs with new benchmarks ?
[16:27:18] <aesteve> mweb: which test is failing exacty ?
[16:29:01] <temporalfox> mweb there should be no vertx when the vertx is craeted
[16:29:12] <temporalfox> mweb it is this line vertx = Vertx.vertx(); ?
[16:29:15] <temporalfox> 36
[16:29:20] <temporalfox> that prints this statement ?
[16:29:33] <aesteve> I do this all the time temporalfox
[16:29:47] <temporalfox> the only way there could be already a context is to use the RunOnContextRule
[16:29:50] <mweb> the fun thing is, that the 3 tests are not failing everytime but I also get the warnings when they succeed. I get the “…are you sure to create a new instance…” message and I also get “Thread Thread[vert.x-eventloop-thread-3,5,main] has been blocked for 2980 ms, time limit is 2000”
[16:30:07] <temporalfox> can you post a stack trace of this logging ?
[16:30:15] <temporalfox> i.e configure your logger to show stack
[16:30:29] <temporalfox> or make a new Exception().printStackTrace()
[16:30:58] <aesteve> https://github.com/aesteve/nubes/blob/master/src/test/java/integration/VertxNubesTestBase.java#L28 ; https://github.com/aesteve/grooveex/blob/master/src/test/groovy/com/github/aesteve/vertx/groovy/specs/TestBase.groovy#L27
[16:31:02] <aesteve> never seen any warning
[16:31:12] <mweb> https://gist.github.com/mcweba/e0801a89a0cade960e4c
[16:31:43] <mweb> I made a gist with the stacktrace
[16:32:21] <aesteve> mmmh
[16:32:27] <aesteve> here your test is just failing : java.lang.AssertionError: Not equals : CONSISTENT != NO_RESULT
[16:33:15] <aesteve> the status message is “CONSISTENT” but you're expecting “NO_RESULT” https://gist.github.com/mcweba/e78c62edffadb45d1c21#file-noclustermembersoneverticleinstancestests-java-L71
[16:33:17] <mweb> thats true but the warnings occur also when the test succeeds
[16:33:46] <aesteve> WARNUNG: Thread Thread[vert.x-eventloop-thread-3,5,main] has been blocked for 2980 ms, time limit is 2000
[16:33:53] <aesteve> this means you're blocking the event loop
[16:34:11] <mweb> and how do I block the event loop?
[16:35:19] <temporalfox> you could lower the blocking detector and have a stack trace printed
[16:35:29] <temporalfox> sometimes the event loop can be blocked in unit tests though
[16:35:34] <temporalfox> and it is necessarily a problem
[16:35:38] <temporalfox> by the test itself
[16:35:57] <temporalfox> like you wait for a countdown on eventloop and are sure that it will be counted down or fail
[16:36:21] <mweb> so this could be a problem in the unit test only?
[16:37:28] <aesteve> we need the stacktrace to actually know, here we just know you're blocking the eventloop, but when it's blocked longer, you get a full stacktrace
[16:37:53] <aesteve> hence temporalfox asking you to lower the blocking detector delay
[16:38:16] <mweb> how do I lower the blocking detector delay?
[16:38:22] <temporalfox> I think it's system property
[16:38:48] <temporalfox> maxEventLoopExecuteTime
[16:38:50] <temporalfox> option
[16:39:27] <temporalfox> actually
[16:39:28] <temporalfox> warningExceptionTime
[16:39:29] <temporalfox> in options
[16:47:38] <mweb> ok I made the changes. see gist https://gist.github.com/mcweba/dca94664e17263106004
[16:48:11] <mweb> it's strange that the logs says time limit is 0
[16:50:17] <mweb> when I run the build with drone.io I don't get the “blocking eventloop” messages: https://drone.io/github.com/mcweba/vertx-cluster-watchdog/6
[17:01:11] <aesteve> at li.chee.vertx.cluster.ClusterWatchdog.start(ClusterWatchdog.java:60)
[17:05:52] <mweb> that's just the creation of ClusterWatchdogHttpHandler. Isn't that allowed there?
[17:06:54] <temporalfox> didn't know drone.io
[17:07:32] <mweb> drone.io is just like codeship.com but with unlimited builds for public repositories
[17:08:34] <temporalfox> so you start a new vertx
[17:08:36] <temporalfox> in your verticle
[17:08:42] <temporalfox> that's where the problem is
[17:08:50] <temporalfox> at li.chee.vertx.cluster.ClusterWatchdogHttpHandler.<init>(ClusterWatchdogHttpHandler.java:15)
[17:08:50] <temporalfox> at li.chee.vertx.cluster.ClusterWatchdog.start(ClusterWatchdog.java:60)
[17:08:51] <temporalfox> at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:111)
[17:08:57] <aesteve> https://github.com/mcweba/vertx-cluster-watchdog/blob/master/src/main/java/li/chee/vertx/cluster/ClusterWatchdogHttpHandler.java#L15
[17:08:59] <temporalfox> I mean you can do that if you like
[17:09:02] <temporalfox>
[17:09:03] <aesteve> that sounds wrong
[17:09:13] <temporalfox> but normally it would be just a “main”
[17:09:21] <temporalfox> that starts vertx with clustered option
[17:09:27] <temporalfox> and deploy the rest
[17:09:33] <mweb> so I should pass the vertx into the ClusterWatchdogHttpHandler?
[17:09:56] <temporalfox> why not make ClusterWatchdogHttpHandler a verticle ?
[17:10:02] <temporalfox> or wrap it with a verticle
[17:10:29] <temporalfox> but this watchdog what does it do ?
[17:10:34] <temporalfox> it starts new vertx instances ?
[17:12:10] <temporalfox> I see
[17:12:10] <temporalfox> Logger log;
[17:12:11] <temporalfox> Router router = Router.router(Vertx.vertx());
[17:12:16] <temporalfox> you should pass it the current vertx
[17:12:33] <temporalfox> in ClusterWatchdog
[17:12:42] <temporalfox> you have
[17:12:42] <temporalfox> new ClusterWatchdogHttpHandler(log, resultQueueLength);
[17:12:49] <temporalfox> add the current vertx of the verticle
[17:12:57] <temporalfox> instead of creating one in the handler
[17:13:23] <mweb> I guess the problem is the Vertx.vertx() in ClusterWatchdogHttpHandler. With vert.x 2.1.2 we used the RouterMatcher and didn't have to use a vertx instance
[17:13:36] <temporalfox> also I think that
[17:13:38] <temporalfox> vertx.createHttpServer().requestHandler(clusterWatchdogHttpHandler).listen(port);
[17:13:45] <temporalfox> you should create the hgttp server in the verticle
[17:13:50] <temporalfox> and when it is started
[17:14:02] <temporalfox> and you set on it directly the handler
[17:14:12] <temporalfox> forget the “and when it is started”
[17:14:30] <temporalfox> so the verticle takes care of starting the web server, set the handler on it
[17:14:37] <temporalfox> and the handler does not really care of the webserver
[17:14:47] <temporalfox> anyway
like you prefer
[17:15:18] <mweb> the verticle is ClusterWatchdog class
[17:15:44] <mweb> the ClusterWatchdogHttpHandler has no reference to the httpserver
[17:18:10] <mweb> I'm passing the vertx instance into the ClusterWatchdogHttpHandler and the warnings are gone
thank you
[17:20:35] <temporalfox> you're welcome!
[17:22:25] <mweb> I don't get your other advice of starting the http server in the verticle and the set it directly on the handler
[19:21:15] *** ChanServ sets mode: +o temporalfox