Differences

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

Link to this comparison view

irc:1446073200 [2017/05/27 13:44] (current)
Line 1: Line 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