Differences

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

Link to this comparison view

irc:1440972000 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:15:24] *** ChanServ sets mode: +o temporalfox
 +
 +[00:15:53] <amr> oh dang
 +
 +[00:15:56] <amr> that was quick :)
 +
 +[00:26:42] <amr> link to PR?
 +
 +[00:58:27] *** ChanServ sets mode: +o temporalfox
 +
 +[01:33:09] <​Sticky>​ amr: https://​github.com/​vert-x3/​vertx-mongo-client/​pull/​38
 +
 +[10:18:39] <​purplefox>​ temporalfox:​ cescoffier pmlopes: morning guys
 +
 +[10:18:49] <​pmlopes>​ good morning
 +
 +[10:18:51] <​cescoffier>​ good morning
 +
 +[10:19:00] <​purplefox>​ good weekend?
 +
 +[10:19:22] <​temporalfox>​ hello all
 +
 +[10:19:32] <​temporalfox>​ good week end, a bit warm though
 +
 +[10:19:53] <​temporalfox>​ I cooked an excellement apricot and mirabelle crumble
 +
 +[10:20:09] <​purplefox>​ what's a mirabelle? a fruit?
 +
 +[10:20:13] <​temporalfox>​ yes
 +
 +[10:20:34] * purplefox googles
 +
 +[10:20:40] <​temporalfox>​ like plum but better taste
 +
 +[10:20:45] <​purplefox>​ a kind of yellow plum it seems
 +
 +[10:20:53] <​temporalfox>​ yes, only raised in some part of france
 +
 +[10:21:19] <​cescoffier>​ it is a kind of plums
 +
 +[10:21:20] <​purplefox>​ i think i have seen this before but i don't think there is a specific name for them here
 +
 +[10:21:31] <​cescoffier>​ smaller, sweeter and yellow
 +
 +[10:22:01] <​purplefox>​ like an apricot but with a smooth skin not a "furry one"
 +
 +[10:22:19] <​purplefox>​ apricot is to mirabelle as peach is to nectarine?
 +
 +[10:22:37] <​purplefox>​ ah the subtleties of fruit nomenclature :)
 +
 +[10:22:56] <​cescoffier>​ nope
 +
 +[10:23:10] <​cescoffier>​ aprocit and mirabelle are very different
 +
 +[10:23:23] <​cescoffier>​ (nectarines are a modification of peachs)
 +
 +[10:24:40] <​purplefox>​ i stand corrected ;)
 +
 +[10:24:47] <​purplefox>​ all prunus though
 +
 +[10:25:20] <​purplefox>​ ah yes, you are quite right
 +
 +[10:25:31] <​purplefox>​ apricot is a different subgenus
 +
 +[10:25:32] <​purplefox>​ https://​en.wikipedia.org/​wiki/​Prunus
 +
 +[10:26:31] <​cescoffier>​ did you see I've moved the web site to the master branch ?
 +
 +[10:26:39] <​purplefox>​ i saw the message
 +
 +[10:26:54] <​purplefox>​ it makes sense
 +
 +[10:27:36] <​pmlopes>​ yes
 +
 +[10:28:34] <​purplefox>​ cescoffier: i'm going to review the stomp stuff today
 +
 +[10:28:43] <​purplefox>​ and try and clear the backlog of to review stuff
 +
 +[10:28:43] <​cescoffier>​ purplefox: ok
 +
 +[10:29:28] <​purplefox>​ pmlopes: temporalfox:​ cescoffier: there are a couple of simple vertx-core PRs to review too, any chance one of you could take a look?
 +
 +[10:29:38] <​cescoffier>​ it's plan for today
 +
 +[10:29:42] <​pmlopes>​ sure
 +
 +[10:29:47] <​temporalfox>​ yep
 +
 +[10:29:51] <​cescoffier>​ as soon as I'm done killing aether
 +
 +[10:30:27] <​temporalfox>​ one should fork and jarjar aether and its dependencies and make a single jar wrapped with a human usable API
 +
 +[10:30:39] <​cescoffier>​ (the divergence with the maven semantic is kind of interesting)
 +
 +[10:32:29] <​purplefox>​ cescoffier: in maven service factory i do something similar so we don't have lots of jars in the distro: https://​github.com/​vert-x3/​vertx-maven-service-factory/​blob/​master/​core/​pom.xml#​L155
 +
 +[10:32:34] <​purplefox>​ (this uses aether too)
 +
 +[10:32:47] <​cescoffier>​ purplefox: yes I need to fix it
 +
 +[10:33:01] <​cescoffier>​ purplefox: is does not follow the right semantic for optional and excluded dependencies
 +
 +[10:33:14] <​purplefox>​ ok
 +
 +[10:33:21] <​cescoffier>​ plus, it should use https://​central.maven.org/​maven2 as main repo
 +
 +[10:36:00] <​purplefox>​ iirc, aether pulls in a load of dependencies that we don't actually need
 +
 +[10:39:14] <​cescoffier>​ it's not the only issue
 +
 +[10:39:32] <​cescoffier>​ it make the dependency graph flat
 +
 +[10:39:49] <​cescoffier>​ so if you wants the full graph you need to collect it while resolving
 +
 +[10:59:30] <amr> Sticky: sweet, thanks :)
 +
 +[11:38:23] <​purplefox>​ cescoffier: pmlopes temporalfox : ha, i've just realised it's a bank holiday in the uk today :)
 +
 +[11:38:37] <​cescoffier>​ :-)
 +
 +[11:38:39] <​purplefox>​ so I might just finish off the stomp review and go and do something else
 +
 +[11:38:54] <​cescoffier>​ what are you celebrating today ?
 +
 +[11:39:32] <​purplefox>​ i don't think there'​s any particular reason just "​august bank holiday"​
 +
 +[11:40:22] <​purplefox>​ "This late summer holiday was originally intended to give bank employees the opportunity to participate and attend cricket matches. How times have changed! Just over a century later, the Banking and Financial Dealings Act 1971 moved this bank holiday to the last Monday in August for England, Wales and Northern Ireland."​
 +
 +[11:40:39] <​purplefox>​ no cricket today, it is pissing with rain
 +
 +[11:40:48] <​cescoffier>​ :-)
 +
 +[11:40:48] <​purplefox>​ not that i like cricket anyway ;)
 +
 +[11:41:09] <amr> ack, ugraded intellij and forgot how i fixed anti aliasing in my old vesion
 +
 +[11:43:28] <​purplefox>​ cescoffier: regarding the stomp stuff...
 +
 +[11:44:02] <​purplefox>​ cescoffier: i don't really understand the acking impl right now, it doesn'​t really seem to do anything
 +
 +[11:44:30] <​cescoffier>​ I've added a comment. It's actually just an overriding mechanism
 +
 +[11:44:52] <​cescoffier>​ to let the user to customize the action to do on ack / nack
 +
 +[11:45:15] <​cescoffier>​ a nack on queue tries to dispatch the frame to another subscriber
 +
 +[11:46:13] <​cescoffier>​ The spec says: "The server can either send the message to a different client, discard it, put it in a dead letter queue"​....
 +
 +[11:47:17] <​cescoffier>​ so it needs a way to let the user customize what happens when a set of messages are acknowledged or not-acknowledged (even if the action on acknowledgement is probably always a noop
 +
 +[11:47:55] <​purplefox>​ ok i think it should also nack all unacked messages on close of subscription
 +
 +[11:49:06] <​cescoffier>​ oh right, it should work that way
 +
 +[11:49:11] <​purplefox>​ this is normal message queue semantcis
 +
 +[11:49:14] <​purplefox>​ however...
 +
 +[11:49:29] <​purplefox>​ right now we aren't queueing messages if there are no subscribers
 +
 +[11:49:44] <​cescoffier>​ nope, I've commented on this one too
 +
 +[11:49:48] <​purplefox>​ so we don't really have queues in the normal meaning in messaging systems
 +
 +[11:49:54] <​cescoffier>​ they are no queue size, we could add this
 +
 +[11:50:19] <​cescoffier>​ (queue size is size of the buffer)
 +
 +[11:50:49] <​purplefox>​ what does getNextSubscription() return if there are no subscripotions?​
 +
 +[11:51:56] <​cescoffier>​ need to check, I would say null
 +
 +[11:52:04] <​purplefox>​ if it's null then you'll get an NPE
 +
 +[11:52:16] <​purplefox>​ (in Queue.java)
 +
 +[11:53:47] <​cescoffier>​ in nack yes
 +
 +[11:54:03] <​cescoffier>​ nope
 +
 +[11:54:14] <​cescoffier>​ it check we can rotate first, so cannot be null
 +
 +[11:54:49] <​cescoffier>​ but in the case we have only one subscriber, it retry on the same one
 +
 +[11:55:02] <​purplefox>​ ok
 +
 +[11:55:15] <​cescoffier>​ which could lead to an infinite loop (if the client don't want this message and nack everytime)
 +
 +[11:55:40] <​purplefox>​ imh.. the logic for acknowledgements subscription.java doesn'​t really belong there, as the behaviour of acknowledgement really depends on the type of destination
 +
 +[11:55:50] <​purplefox>​ e.g. for a simple topic subscription it's a No-op
 +
 +[11:56:00] <​purplefox>​ for a more complex queue subscriptiont then you can keep track
 +
 +[11:56:07] <​purplefox>​ for some other subscription maybe something else
 +
 +[11:56:23] <​purplefox>​ so I'd let the destination create the subscription
 +
 +[11:56:41] <​purplefox>​ then it can return a subscription implementation that makes sense for the destination
 +
 +[11:56:59] <​purplefox>​ e.g. you could have a nested class subscription impl for queue in Queue.java
 +
 +[11:57:33] <​purplefox>​ right now it's imposing overhead on each implementation even if it doesn'​t care
 +
 +[11:58:20] <​cescoffier>​ actually, subscriptions need to be handled globally.
 +
 +[11:58:41] <​cescoffier>​ (because there are rules such as client cannot use the same '​id'​)
 +
 +[11:59:26] <​purplefox>​ that check can be done "​globally",​ but that doesn'​t mean the logic of ack needs to be the same for all subscriptions
 +
 +[11:59:58] <​purplefox>​ personally I would try and keep things simple for now, and do the minimum mandated by the spec - i.e. no-op for acks
 +
 +[12:00:16] <​purplefox>​ once you get into implementing real queues things start to get complex
 +
 +[12:00:20] <​purplefox>​ with redelivery etc
 +
 +[12:01:49] <​purplefox>​ for a simple stomp mapping onto event bus you don't need acks anyway
 +
 +[12:01:54] <​purplefox>​ as event bus doesn'​t support acks
 +
 +[12:02:44] <​purplefox>​ the last thing you want to do here is end up writing a new messaging system ;)
 +
 +[12:02:48] <​cescoffier>​ actually, queue and topic can re-implement their own subscription
 +
 +[12:02:53] <​cescoffier>​ they are managing the subscriptions
 +
 +[12:03:29] <​purplefox>​ ok cool, so they just need to have their own Subscription implementation :)
 +
 +[12:03:54] <​purplefox>​ but.. i would warn against putting too much "​messaging logic" into the stomp server
 +
 +[12:04:06] <​cescoffier>​ yes, for topic, we should have one that does nothing on ack / nack
 +
 +[12:04:09] <​purplefox>​ or you will end up writing your own messaging system and trust me that is a can of worms ;)
 +
 +[12:04:31] <​cescoffier>​ already implemented the event admin for OSGi (no queue, topic only), and yes I know ....
 +
 +[12:05:16] <​purplefox>​ yeah believe me if you implement queues, someone will ask for bounded queues, and dead letter queues, and priority queues, and last value queues, and the ability to view queues in memory, etc, etc
 +
 +[12:05:18] <​cescoffier>​ one thing we can do, is just remove all ack / nack logic as people can implement their own type of destination
 +
 +[12:05:56] <​purplefox>​ yes I think this is preferable - just ship with a very simple implementation which bridges to the vert.x event bus and
 +
 +[12:06:11] <​purplefox>​ users who want something more complex can implement it themselves
 +
 +[12:06:14] <​cescoffier>​ that would also remove the redelivery on nack (in queue)
 +
 +[12:06:26] <​purplefox>​ yes, ack and nack would be no-ops
 +
 +[12:06:30] <​cescoffier>​ what about queue buffer ?
 +
 +[12:06:32] <​purplefox>​ as event bus doesn'​t support them anyway
 +
 +[12:06:40] <​purplefox>​ wouldn'​t need that either
 +
 +[12:06:45] <​cescoffier>​ ok
 +
 +[12:07:08] <​cescoffier>​ I will remove these features (and the related tests)
 +
 +[12:07:08] <​purplefox>​ basically dispatch would either be event bus send or publish
 +
 +[12:08:55] <​cescoffier>​ ok
 +
 +[12:09:03] <​cescoffier>​ I do that just after lunch
 +
 +[12:42:44] <​s0va>​ hello
 +
 +[12:42:50] <​s0va>​ http://​pastebin.com/​XP8NTc76
 +
 +[12:42:56] <​s0va>​ i'm porting my app to vertx3
 +
 +[12:43:22] <​s0va>​ ... my problem is that i don't get notified when consumer has been registered all over the cluster
 +
 +[12:43:41] <​s0va>​ looks cosumer.handler() argument is never invoked
 +
 +[12:44:29] <​s0va>​ what am i doing wrong?
 +
 +[12:48:15] <​s0va>​ oh, looks like javadoc is wrong.
 +
 +[12:48:25] <​s0va>​ .completionHandler() is the key.
 +
 +[12:55:41] <​purplefox>​ s0va: can you show me where the javadoc is wrong, so we can fix it?
 +
 +[13:57:23] <​s0va>​ purplefox: just a sec
 +
 +[13:58:39] <​s0va>​ https://​github.com/​eclipse/​vert.x/​blob/​master/​src/​main/​java/​io/​vertx/​core/​eventbus/​MessageConsumer.java#​L30
 +
 +[13:59:13] <​s0va>​ s0va: should be completionHandler()
 +
 +[14:42:15] <​purplefox>​ s0va: looks correct to me already
 +
 +[14:56:59] <​s0va>​ Registration * is effective after the {@link #​handler(io.vertx.core.Handler)} method is invoked.<​p>​
 +
 +[14:57:41] <​s0va>​ that's technically true, but registration is actually active when completionhandler()'​s argument is invoked
 +
 +[15:19:14] <​pmlopes>​ @purplefox @cescoffier @temporalfox:​ I had another post in the queue this time about web app security: see the draft here: https://​github.com/​pmlopes/​vertx-web-site/​blob/​secure-webapps/​src/​site/​blog/​posts/​vertx3-secure-webapps.md The post is already 200 lines long and I did not cover sql/nosql security do you guys think i should also lightly cover it? or just keep references to OWASP best practices?
 +
 +[15:19:33] <​cescoffier>​ pmlopes: I've published the previous one this morning
 +
 +[15:19:47] <​temporalfox>​ I should blog sometime :-)
 +
 +[15:19:54] <​pmlopes>​ yes i know, this would be something that would be considered done, next week or so...
 +
 +[15:20:36] <​cescoffier>​ I think adding the references would be enough
 +
 +[15:21:08] <​purplefox>​ s0va: yes, the javadoc for completion handler is pretty explicit on this: "​Optional method which can be called to indicate when the registration has been propagated across the cluster."​
 +
 +[15:27:53] <​s0va>​ is vertx.close() equivalent of container.exit() in vertx.2?
 +
 +[15:33:38] <​pmlopes>​ @temporalfox are any plans support language specific properties? for example on vert.x web expose the context properties as properties from the object it self and not a getter: e.g.: ctx.param1 instead of ctx.get("​param1"​) the reason is that someone asked if we could have a dot in a property name and in that case i think i need to say so otherwise we cannot have stuff like: ctx.param.1 since it would break the compiler i think...
 +
 +[15:34:33] <​temporalfox>​ the problem is that for read-only properties we cannot know if that's a proeprty or a method
 +
 +[15:35:08] <​temporalfox>​ ah hum let me reread you again
 +
 +[15:35:48] <​temporalfox>​ I am not sure to understand what "​ctx.get("​param1"​)"​ means
 +
 +[15:36:15] <​temporalfox>​ ah you would like maybe to support something like getAt putAt in Groovy ?
 +
 +[15:36:29] <​temporalfox>​ so if an object has getAt(String) putAt(String,​Object)
 +
 +[15:36:39] <​temporalfox>​ then codegen understands it specially and it means it's a map like structure ?
 +
 +[15:40:00] <​pmlopes>​ yes but in that case we should not allow property names like: param.1 right?
 +
 +[15:42:53] <​temporalfox>​ so first we would need to agree on a way to expose properties natively in a language
 +
 +[15:43:17] <​temporalfox>​ then indeed there could be a conflict depending on the language
 +
 +[15:43:41] <​temporalfox>​ and in that case we should not use "​."​ for properties name
 +
 +[15:43:51] <​temporalfox>​ unless it is handled by the implementation tiself
 +
 +[15:43:57] <​temporalfox>​ i.e in Context
 +
 +[15:44:13] <​temporalfox>​ put("​abc.def"​) -> creates an intermediary Map for "​abc"​
 +
 +[15:44:18] <​temporalfox>​ and store "​def"​ in that map
 +
 +[15:44:34] <​temporalfox>​ get I think doing something like "​ctx.abc.def"​ could work
 +
 +[15:44:42] <​temporalfox>​ for dynamic languages
 +
 +[15:44:57] <​temporalfox>​ and the code generator should do some work to adapt the object
 +
 +[15:45:11] <​temporalfox>​ for instance if it returns a Map
 +
 +[15:45:25] <​temporalfox>​ then in js it's mapped to json
 +
 +[15:45:33] <​temporalfox>​ and in  groovy I think we keep map
 +
 +[15:45:35] <​temporalfox>​ and in ruby hash
 +
 +[15:45:41] <​temporalfox>​ so that might work
 +
 +[15:48:03] <​pmlopes>​ ok, so i will mark that issue as won't fix for now
 +
 +[20:16:58] <​BadApe>​ i am trying to write some unittest for a tcp server, i must have done something wrong because during the server starts but the server doesn'​t start the test
 +
 +[20:17:06] <​BadApe>​ vertx.deployVerticle(TCPServerVerticle.class.getName(),​ context.asyncAssertSuccess());​
 +
 +[23:19:37] *** ChanServ sets mode: +o temporalfox
 +
 +[23:25:03] <​jtruelove>​ are there any docs around on implementing a metrics SPI? I wanted to hook that up for vertx-opentsdb and vertx-bosun maybe
 +
 +[23:34:40] <​BadApe>​ heck i am just having trouble writing unittest for the simple tcp service
 +
 +[23:49:06] <​BadApe>​ stupid unittests are complete before the test runs