Approvals: 0/1
[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