[01:54:42] <woorea> hi

[01:55:18] <woorea> how you manage authorization in a multitenant environment?

[01:55:35] <woorea> using a blockingHandler and query the database?

[08:42:28] * ChanServ sets mode: +o temporalfox [09:22:56] * ChanServ sets mode: +o purplefox

[11:05:14] <tsegismont> temporalfox, hi, has vertx unit timeout rule impl change recently?

[11:05:39] <tsegismont> I'm writing a test, for DatagramSocket metrics

[11:05:52] <tsegismont> I have this declared in the junit test case

[11:06:05] <tsegismont> @Rule

[11:06:05] <tsegismont> public Timeout timeout = new Timeout(1, MINUTES);

[11:06:39] <tsegismont> the test keeps running after one minute

[11:38:41] <Michel_> hello

[11:39:26] <Michel_> has anyone been using service proxies on a cluster ?

[11:39:51] <Michel_> I think there is an annoying bug (https://groups.google.com/d/topic/vertx/7pMZEMsjZNE/discussion)

[11:40:35] <Michel_> My company and I are very interested in fixing this as this represent a blocker for us (we're running one mongo service on a cluster)

[11:41:01] <purplefox> Michel_: please file a github issue against the mongo client repo so the maintainer sees it

[11:41:21] <Sticky_> tsegismont: I noticed suddenly yesterday that the timeout started acting differently for no reason at all

[11:41:33] <Michel_> I'm afraid the bug relies in the code generation of the service proxy

[11:41:34] <purplefox> Michel_: Sticky_ is the maintainer :)

[11:41:44] <Michel_> haha

[11:41:57] <Sticky_> yo

[11:42:12] <Sticky_> chose the wrong time to pipe up clearly

[11:42:25] <Michel_> indeed

[11:43:00] <Michel_> As I tried to explained on the dev group, the issue is in the code gen template of the service proxy. (I think)

[11:43:44] <purplefox> Michel_: but as a general point, don't rely on all maintainers to constantly scan the google group. it always make sense to submit an issue

[11:43:49] <Michel_> I'll create a PR on the vertx-service-proxy github project.

[11:43:51] <Michel_> sure

[11:44:24] <temporalfox> tsegismont I don't think so

[11:44:38] <tsegismont> ha

[11:44:46] <temporalfox> tsegismont what changed is that the timeout thread is now interrupted once the test case is done

[11:44:48] <tsegismont> it worked last week

[11:45:06] <temporalfox> tsegismont maybe it caused a regression ?

[11:45:08] <tsegismont> so something changed :)

[11:45:13] <tsegismont> I guess so

[11:45:14] <temporalfox> yeah something changed

[11:45:19] <temporalfox> for sure

[11:45:28] <temporalfox> it hasn't break any test though

[11:45:35] <temporalfox> can you tell me what is the problem ?

[11:45:47] <tsegismont> If you loop in your test code and have #sleep calls

[11:45:55] <tsegismont> then the loop is not exited

[11:45:59] <Sticky_> I have also seen the behaviour change. I saw a test that I had rigged to run for Integer.MAX_INT duration suddenly start timing out after 20 seconds

[11:46:21] <tsegismont> I suppose before the change the #sleep call failed correctly with InterruptedException

[11:46:50] <Sticky_> tsegismont: are you setting the @Rule in a super class of your test

[11:47:01] <tsegismont> Sticky_, yes

[11:47:08] <Sticky_> yeah that was my problem

[11:47:17] <Sticky_> I had to move it down to the test class

[11:47:42] <temporalfox> why do you need sleep ?

[11:47:44] <tsegismont> I'm almost sure it worked withe the rule in parent class before

[11:48:06] <Sticky_> tsegismont: it did for me too, until yesterday

[11:48:06] <temporalfox> if you can provide a simple reproducer it would be nice

[11:48:19] <temporalfox> I added a couple of features recently in vertx unit

[11:48:27] <temporalfox> like repeatability of a test case

[11:48:37] <temporalfox> useful for race condition reproducing

[11:49:16] <tsegismont> #sleep in end-to-end testing can be useful

[11:49:44] <temporalfox> ok

[11:49:53] <temporalfox> also if you are using countdown latches

[11:50:05] <temporalfox> now you can use Async to hae a similar behavior

[11:51:29] <tsegismont> I've stopped using countdown latches since you pointed me to vertx-unit :)

[11:51:41] <tsegismont> thanks Sticky_ for the workaround

[11:51:53] <Sticky_> heh, take it, it worked?

[11:51:55] <temporalfox> ah yes but sometimes it is useful from the main thraed

[11:52:05] <temporalfox> if you want to run code from main junit thread

[11:52:10] <temporalfox> so you create an async

[11:52:15] <temporalfox> resolve the async somewhere

[11:52:16] <temporalfox> and do

[11:52:24] <temporalfox> async.assertSuccess()

[11:52:28] <temporalfox> actually

[11:52:32] <temporalfox> async.awaitSuccess();

[11:52:49] <temporalfox> so the junit thread blocks until the async is resolved

[11:53:17] <temporalfox> allows to have less nested logic

[11:53:25] <temporalfox> and remove some callback hell

[11:53:27] <temporalfox> more sequential

[11:53:31] <temporalfox> steps

[11:53:32] <tsegismont> Sticky_, no.. but thanks, still ;)

[11:53:43] <Sticky_> heh, ok

[11:53:51] <temporalfox> anyway if you can describe the behavior it's be very cool

[11:54:13] <tsegismont> will do

[11:54:57] <tsegismont> by the way , round robin on servers, it's only for http servers, right?

[11:55:32] <tsegismont> I'm referring to http://vertx.io/docs/vertx-core/java/#_server_sharing

[11:57:01] <temporalfox> no it is also for TCP

[11:57:37] <tsegismont> temporalfox, ok, but not UDP

[11:57:41] <tsegismont> ?

[11:57:43] <temporalfox> tsegismont I'm not sure of that

[11:57:57] <temporalfox> it would make sense it does

[11:58:05] <temporalfox> but I've never checked the code actually

[11:58:25] <temporalfox> never been really in Datagram of vertx codebase

[11:58:29] <temporalfox> will have a look now

[11:59:45] <Michel_> would'nt that be a bit weird ? You don't have streams in UDP…

[12:00:22] <temporalfox> I think he was more mentionning for deliery datagrams

[12:00:26] <temporalfox> to different event loops

[12:00:35] <temporalfox> it seems there is nothing specific

[12:00:42] <temporalfox> and I don't see anything in test case

[12:00:52] <temporalfox> now maybe that netty handles it internally too

[12:01:01] <temporalfox> not very familiar with UDP programming

[12:38:34] <tsegismont> temporalfox, maybe it does, but only if you create multiple vertices

[12:38:38] <tsegismont> I need to try

[12:38:43] <temporalfox> yes

[12:39:28] <tsegismont> ok

[12:39:34] <tsegismont> time for lunch

[12:39:38] <tsegismont> :)

[14:29:43] <tsegismont> temporal_, https://github.com/vert-x3/vertx-unit/issues/24

[14:29:48] <temporal_> ok

[14:30:37] <temporal_> will have a look now

[15:02:21] <purplefox> rajith: hi, are you there?

[15:04:45] <rajith> purplefox: just woke up … didn't have much sleep last night. Wasn't feeling well

[15:04:55] <rajith> purplefox: btw I forgot to push last night

[15:05:06] <rajith> purplefox: I saw your email .. I'm able get it to work end to end

[15:05:39] <purplefox> np. can you push now please?

[15:05:40] <rajith> purplefox: did you make any changes ? I will change the git commits before I pull

[15:05:47] <purplefox> you should pull first

[15:05:52] <rajith> I meant I will chekc

[15:05:53] <purplefox> i added a first test

[15:05:53] <rajith> yea

[15:06:12] <purplefox> i was going to work on this today but was exepecting your push this morning

[15:06:16] <purplefox> so I couldn't do much

[15:06:46] <rajith> purplefox: I'm sorry last afternoon evening I had to do other things .

[15:06:58] <rajith> purplefox: let me first do a quick test end-to-end before I push

[15:07:26] <purplefox> the test I added (trivial send/consume) should work but it doesn't due to some problem with the addressing

[15:15:12] <purplefox> i think it's important that we start using tests properly and not relying on manually starting/stopping servers and “examples”

[15:15:50] <tsegismont> temporal_, I have a verticle extending GroovyVerticle. When I try to deploy programatically vertx.deployVerticle(DatagramServerVerticle.class.name), I get this error: java.lang.ClassCastException: io.vertx.ext.hawkular.DatagramITest$DatagramServerVerticle cannot be cast to io.vertx.core.Verticle

[15:16:11] <temporal_> you need to prefix with “groovy:”

[15:17:02] <tsegismont> temporal_, “groovy: ${DatagramServerVerticle.class.name}” ?

[15:17:09] <temporal_> yes I think

[15:17:18] <temporal_> who compiles groovy source code ?

[15:17:21] <tsegismont> will try

[15:17:40] <tsegismont> gmavenplus-plugin

[15:18:29] <temporal_> I mean

[15:18:38] <temporal_> why do you care about compiling such verticle

[15:18:44] <temporal_> and don't let vertx do it for you

[15:18:54] <temporal_> that would avoid you to have an extra maven phase

[15:19:11] <tsegismont> ha

[15:19:27] <tsegismont> because the junit tests are written in Groovy

[15:19:33] <tsegismont> and started with surefire

[15:19:42] <tsegismont> so I have to get them compiled first

[15:19:46] <temporal_> ok

[15:20:06] <temporal_> still you can have this verticle

[15:20:11] <temporal_> as a simple groovy script

[15:20:16] <temporal_> in test/resources

[15:20:21] <temporal_> no need to extend a class

[15:22:20] <tsegismont> trying

[15:22:33] <tsegismont> temporal_, but there's an issue right?

[15:22:41] <tsegismont> I like to file issues :)

[15:22:49] <temporal_> no there is no issue

[15:23:07] <temporal_> you could hve your java verticle as groovy

[15:23:13] <temporal_> too

[15:23:20] <temporal_> but you need 2 classes

[15:23:27] <temporal_> one for the java verticle launcher

[15:24:15] <temporal_> if you extend GroovyVerticle you have a verticle for the GroovyVerticleFactory

[15:25:55] <tsegismont> not sure I follow, there's no Java verticle involved

[15:26:10] <tsegismont> and the vertx instance I'm working with is a io.vertx.ext.hawkular.BaseITest#vertx

[15:26:22] <tsegismont> sorry io.vertx.groovy.core.Vertx

[15:27:02] <tsegismont> so you're saying it's not possible to deploy a GroovyVerticle with in a io.vertx.groovy.core.Vertx instance?

[15:58:52] <rajith> purplefox: the end-to-end weather example works over dispatch … I'm now working through the mock server errors I'm seeing

[16:29:23] <gemmellr> rajith: mockserver as in the one from vertx-proton?

[16:33:55] <rajith> gemmellr: no this was using dispatch

[16:34:09] <rajith> gemmellr: the mock server doesn't work .. looking through it now

[16:35:54] <gemmellr> rajith: yeah, im asking what mock server you are talking about…mainly as if its the one from vertx-proton, its very very basic and may not be capable of whatever it is you are trying

[16:38:45] <purplefox> yes the one from vertx-proton

[16:38:58] <purplefox> we are just trying to get a trivial example of sending and consuming a message to work

[16:39:06] <rajith> gemmellr: purplefox yea I'm making some changes to make the basic test case working … almost there

[16:39:08] <purplefox> the most basic use case

[16:40:05] <rajith> gemmellr: purplefox I just to match the source and target so a basic send/consume can work .. it's good enough for now

[16:40:15] <purplefox> gemmellr: it would be nice if there was an embeddable amqp server that we could stick in a jar somewhere and push to maven, then it could be used by multiple projects

[16:40:31] <gemmellr> purplefox: ok, so you want it to accept a message from a producer to a certain address, and send that message back to a consumer? That isn't something it does yet becuase it doesnt need to for the tests..but easy enough to wire up

[16:41:16] <purplefox> what would be better would be something that more closely mimics an amqp broker

[16:41:24] <purplefox> e.g. an embeddable a-mq or artemis

[16:41:41] <gemmellr> purplefox: there are a few java brokers out there one could use

[16:41:45] <purplefox> iirc, hornetq used to be fully embeddable, but I haven't looked at it for a long time

[16:42:18] <purplefox> is this not something you guys have done before?[unknown:nbsp]i'm assuming in your test suites you have a need to start and stop embedded servers all the time?

[16:44:22] <gemmellr> purplefox: for the jms client we use a combination of a an embedded ActiveMQ 5 broker, and a test peer we instruct at a fairly low level about the AMQP traffic to expect and validate and what to send back

[16:44:52] <gemmellr> purplefox: a simpler 'test broker' is something we have mentioned adding but have yet to do so

[16:45:25] <purplefox> embedded activemq is fine

[16:56:31] <rajith> purplefox: ok the test works .. hacked a basic mock server by making some simple changes

[16:57:02] <rajith> purplefox: we can refine that as an when needed or switch if a better one is made available to us … give me 5 to commit and push

[16:57:37] <purplefox> as long as we have a “broker” which implements basic queues and topics I think we are good for testing

[17:00:14] <chirino> Eventually it would be nice to have itests against as many official AMQP brokers we can easily test against.

[17:02:23] <chirino> gemmellr: pr merged.

[17:02:55] <gemmellr> chirino: great, thanks

[17:02:58] <chirino> we eventually need to sort out how to expose sasl in the api too

[17:03:27] <chirino> purplefox: are there any other vert.x protocols using sasl?

[17:04:24] <purplefox> chirino: +1

[17:04:26] <gemmellr> personally I'd make it use sasl all the time, even if it just uses anonymous…anything that supports no-sasl should support anonymous

[17:05:08] <gemmellr> adding a toggle to disable if needed

[17:07:20] <rajith> purplefox: the test was running in a never ending loop bcos the same address is used on send & recv … I can see a few users tripping on this

[17:07:28] <rajith> purplefox: I pushed .. the test case now works

[17:08:16] <rajith> purplefox: we just need to build from there … the mock server was to basic store-and-forward we can polish that up and add support for topics

[17:55:28] <purplefox> rajith: ok thanks, I've pushed a little bit of cleanup. Don't have time to do any more today, and I'm away tomorrow, but will work more on it on Monday

[17:57:47] <purplefox> rajith: can you please push the code about the mappings between vert.x and amqp addresses that we talked about earlier?

[18:32:58] <purplefox> rajith: ping

[21:18:17] *** ChanServ sets mode: +o temporalfox