Differences

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

@@ Line 1: / Line 1: @@
+[10:42:14] <cescoffier> hi davsclaus
+[10:42:16] <davsclaus> cescoffier okay got some code
+[10:42:32] <davsclaus> will do a PR shortly with 50% done
+[10:42:46] <cescoffier> cool, what are you improving ?
+[10:43:03] <davsclaus> https://github.com/vert-x3/vertx-camel-bridge/pull/1
+[10:43:12] <davsclaus> to leverage camel's routing engine correctly
+[10:43:21] <davsclaus> same kind of work needed in the outbound
+[10:43:26] <davsclaus> will take a look in a while
+[10:44:41] <cescoffier> so you use AsyncProcessor
+[10:44:51] <cescoffier> in which thread is this processor called ?
+[10:45:20] <davsclaus> the camel consumer
+[10:45:23] <cescoffier> (same question for callback.done())
+[10:45:32] <cescoffier> so a thread pool managed by camel
+[10:45:33] <davsclaus> but the reply part is the vertx thread
+[10:45:55] <davsclaus> so if you do reply then you can "free" the consumer thread
+[10:45:59] <davsclaus> when you return false
+[10:46:25] <davsclaus> and leave it to vertx to resume the work when it has the reply
+[10:46:50] <cescoffier> ok, cool
+[10:47:08] <davsclaus> sadly AsyncProcessor is not a single interface so its not java 8 lambda readyu
+[10:47:11] <cescoffier> looks much better than my attemp to check in the exchange was InOut
+[10:47:42] <davsclaus> i will give a go on the outbound side as well and do a PR there
+[10:47:56] <DP_2014> Hi,  I have  created a web  app but as  its getting more and more complex with  hundreds or routes   and handlers It becoming really messy,  passing RoutingContext areound every wherem  anyone know of a good structure  to group and inherit handler functionality?
+[10:49:21] <cescoffier> DP_2014 : the handler don't have to be in the same class, you can create one class per handler if you want
+[10:50:32] <DP_2014> yes i have done that and grouped handlers in classes like controllers,  but when i want  base functionalitly and  inherit the only way i can get  around it is passing REouting context to each method
+[10:50:52] <DP_2014> sorry passing RoutingContext
+[10:52:05] <DP_2014> this is all pretty much  just like  controllers no other services I ahve about 20 other verticles that handle all the services, I am having trouble with the complexity of the routing
+[10:55:36] <DP_2014> has anyone used routing with hundreds of routes?
+[10:59:14] <cescoffier> ping pmlopes
+[11:00:13] <cescoffier> pmlopes : DP_2014 has a question for you
+[11:01:32] <DP_2014> Lol,     I need extension methods like they have in C#
+[11:01:56] <pmlopes> @DP_2014 the routing context is a dynamic object it represents the request so you cannot use it as a class variable and set it once on the contructor
+[11:02:23] <DP_2014> yes i know,   so i have to pass it to every method
+[11:02:24] <cescoffier> davsclaus : I've merged your PR, re-eanbled the skipped test (as replies work now), and externalize the helper method into a Helper class.
+[11:02:36] <davsclaus> cescoffier  nice
+[11:03:01] <cescoffier> davsclaus it starts to look pretty good (planning a write a blog post about it)
+[11:03:02] <pmlopes> now depending on your objects you could use a generator like approach, you could have a generic class that on its handler method creates a new object of your classes and in that case it will have the routing context in the contructor
+[11:03:17] <pmlopes> but this object cannot live longer than the request itself
+[11:03:28] <DP_2014> yes thats what i have bee nthinking on
+[11:10:26] <DP_2014> pmlopes do you  see any downside in that approach?
+[11:11:46] <DP_2014> I am also struggling with hundreds of route combination methods, with either a tonne of routes or a switch/case statment in the classes to direct to the correct method?  Am i missing  something obvious?
+[11:12:41] <pmlopes> @DP_2014 if your objects do not do any long initialization, say for example that only set the RC to a object state, then I see them as a extended lambda so performance wise it should be negletable
+[11:13:23] <pmlopes> @DP_2014 if you need switch cases to route to the right method, i guess that your API is not as simple as it should be, it shows that you have overlaping
+[11:13:34] <pmlopes> maybe you should revisit that too
+[11:14:00] <DP_2014> sorry   I can either have  hundreds of routes ,   or simple routes   and then swtich statements
+[11:14:10] <pmlopes> of course i'm saying this without looking at code
+[11:14:45] <pmlopes> out of curiosity what kind of system are you building to require hundreds of routes?
+[11:16:16] <DP_2014> Its a business system that is being ported  for social collaborative scale
+[11:17:39] <DP_2014> so full crm, financial accounting, manufacturing , hr, inventory, etc  but on a collaborative model
+[11:18:08] <pmlopes> so if you have simple routes and switch statement how would that look like?
+[11:18:38] <DP_2014> it has been ported from c#
+[11:18:49] <DP_2014> taken about a year to port
+[11:19:35] <DP_2014> "//area1/action1 /area1/action2    ../areaN/actionN"
+[11:20:14] <DP_2014> ite gets more complex than that
+[11:20:33] <DP_2014> but router.route("/:vtxarea/:vtxaction")
+[11:21:22] <pmlopes> so you could get a simple route with vars like "/:area/:action" and the handler would then create a object that would contain the RC and be suited to handle a specific area+context type
+[11:21:34] <DP_2014> but its ususally within areas like   router.route("/person/:vtxarea/:vtxaction").handler(programHandler);
+[11:21:41] <DP_2014> but its ususally within areas like   router.route("/person/:vtxarea/:vtxaction").handler(personHandler);
+[11:23:29] <pmlopes> i guess you can hide the switch statements inside the constructor of your object or use some other smarter technique
+[11:24:02] <pmlopes> like some hashing given the set of variables give me the object type that can handle it
+[11:26:23] <DP_2014> or more clearly the  url would be something like     "/inventory/widget1/stock"        would   show stock levels for widget1  and   "/inventory/widget1/purchasing"     would show purchasing for widget1  handler would be inventoryHandler  ie.   router.route("/inventory/:vtxid/:vtxaction").handler(inventoryHandler); but in the inventory handler i have massive case statment for all the possible...
+[11:26:24] <DP_2014> ...actions
+[11:26:58] <DP_2014> now multipply this for tens of module areas,
+[11:29:41] <pmlopes> well, you could try to handle this the other way around, so say you have the route: "/inventory/:vtxid/:vtxaction" you first add a handler that only looks at "vtaction" and sets the right object in the context "ctx.put("vtAction", new MyVTActionHandler(ctx, ctx.getParam("vtaction"))); and then ctx.next()
+[11:30:04] <pmlopes> now on the following handler you always have the handler type resolved so no need to switch statements
+[11:30:57] <pmlopes> you just  need to do ctx.get("vtAction").runMyBusinessLogic(...) and what ever extra needed
+[11:35:30] <DP_2014>  .../stock action will call  a method like a stock() that has completely different business  logic than  .../purchasing   purchasing().   also   if person puts  url   /inventory/widget1/badRequest      it will still be picked up by the route but is invalid?         I do chain the handlers now  to    session - >  auth -> data handler ->db handler - >render/repsonse handler          but in the...
+[11:35:31] <DP_2014> ...middel the data and bus
+[11:37:57] <pmlopes> you can validate if the action is valid, say having a list of valid actions and do something like: if (!actionsList.contains(ctx.getParam("vtaction"))) { ctx.fail(400); } else { ctx.next(); }
+[11:38:12] <DP_2014> sorry, don't mean to be coming across as being argumentative, your advice  has been great,  especially the   geneerator approach!!    I am just trying to get my head around  all the issues
+[11:49:28] <davsclaus> cescoffier a PR with the outbound implemented
+[11:49:33] <davsclaus> https://github.com/vert-x3/vertx-camel-bridge/pull/2
+[11:53:23] <cescoffier> thanks davsclaus, gonna have a look after lunch
+[12:26:02] *** ChanServ sets mode: +o temporal_
+[13:22:18] <cescoffier> davsclaus : back, having a look
+[13:36:49] <BadApe> i am using postgresql and the json field type, when i encode the result, the json object field gets converted to a string
+[13:36:55] <BadApe> is there anyway around this?
+[13:38:41] <cescoffier> BadApe: are you using the mysql/postgres client or the JDBC async client ?
+[13:38:48] <BadApe> jdbc client
+[13:39:27] <BadApe> MySQL / PostgreSQL client says tech preview
+[13:39:40] <cescoffier> BadApe : I'm not sure we support the Json type. So it is probably passed as a String, and you would need to recereate the Json Object out of it
+[13:39:57] <cescoffier> BadApe : yes the MySQL / Postgres client is a tech preview
+[13:40:05] <BadApe> http://vertx.io/blog/vert-x3-and-postgresql-json-type/ :)
+[13:40:20] <cescoffier> davsclaus : merged ! Thanks ! I've updated the documentation. So now it's time for the vert.x team review
+[13:40:24] <BadApe> there is some support :)
+[13:40:53] <cescoffier> BadApe : didn't read this article, I should ;-).
+[13:40:56] <davsclaus> you may want to add a bit debug/trace logging on the points where camel and vertx "change hands"
+[13:41:02] <davsclaus> it may help during some debugging etc
+[13:42:04] <BadApe> i read all the blog posts, very enlightening for a newbie
+[13:42:27] <BadApe> they should be changed into a beginners guide
+[13:42:31] <cescoffier> BadApe : in the snippet, line 88:  // here we return the document and note that i don't need to convert from JsonObject to String, PostgreSQL returns JSON as strings so less conversions, better performance!
+[13:43:20] <cescoffier> davsclaus : yes, it would make sense to add a few log, I've done basic thread check to be sure we don't block the event loop
+[13:43:36] <BadApe> i guess i will have to loop over the results
+[13:44:21] <BadApe> it doesn't make using the json field type very useful for a rest interface
+[13:45:06] <cescoffier> BadApe : as far as I understand, it's postgres that returns String objects
+[13:45:12] <davsclaus> cescoffier +1
+[13:46:18] <BadApe> maybe i shouldn't use the json field type
+[13:56:53] <BadApe> oh it was easier to manually covert it
+[13:57:01] <BadApe> shame i don't know which are json fields
+[17:26:51] <BadApe> so i don't really want to write a failure handler for every route, can i do something like http://pastebin.com/BZzf1FWM
+[20:38:22] <jtruelove_> temporal_ has there been any thought on allowing AbstractVerticle to have an override like getVertxOptions where you could configure a custom SPI or something for instance
+[20:38:41] <jtruelove_> i feel like i've asked this before but there was a chicken and egg problem with that
+[22:41:31] <temporal_> jtruelove_ yes it would be a problem and it would also complexify, a verticle should not own a configuration for vertx
+[22:41:41] <temporal_> what is the problem you are trying to solve ?
+[22:52:34] *** ChanServ sets mode: +o temporalfox
+[23:11:28] <jtruelove_> it would be nice to use say vertx-opentsdb and still use abstractverticle
+[23:11:42] <jtruelove_> but you need to specify config VertxOptions in order to config the SPI
+[23:16:12] <jtruelove_> temporal_ ^
+[23:27:07] <jtruelove_> err temporalfox ^
+[23:27:41] <temporalfox> jtruelove_ btw have you seen my mail about Thomas Segismont work on metrics ?
+[23:28:48] <temporalfox> jtruelove_ what is your use case exactly ?
+[23:28:52] <temporalfox> I mean how do you use it ?
+[23:31:05] <jtruelove_> i saw a mail I have not fully pondered it, it sounded if I'm remembering correctly akin to some things that julien and i discussed a bit back
+[23:31:30] <temporalfox> I'm julien :-)
+[23:32:02] <jtruelove_> well then you :) never sure which is the real fox in here
+[23:32:22] <jtruelove_> well we write most of our services using AbstractVerticle and a fatjar manifest that points at that implementor, doing that doesn't allow you to easily integrate with SPI
+[23:32:45] <jtruelove_> unless you make a wrapper verticle for injecting our custom vertx-opentsdb options etc..
+[23:32:55] <temporalfox> you could make your own verticle factory perhaps
+[23:33:06] <jtruelove_> so a while back when i did SPI we discussed it and hawkular and some of the similarities
+[23:33:11] <temporalfox> that setup opentsdb options
+[23:33:21] <temporalfox> based on the verticle class or annotations
+[23:33:58] <temporalfox> actually : chicken egg problem
+[23:34:24] <jtruelove_> yeah, you have to start the verticle with the vertxoptions
+[23:34:38] <jtruelove_> it's how the SPI shit gets injected ultimately right
+[23:34:41] <temporalfox> I think the best if you use a fat jar is to make your own Launcher
+[23:34:48] <temporalfox> and extend the exisint CLI launcher
+[23:34:58] <jtruelove_> yeah which will take the insatnces args and things and pass them in
+[23:35:11] <jtruelove_> and just start the verticle
+[23:35:11] <temporalfox> it will prepopulation the options
+[23:35:13] <temporalfox> yes
+[23:35:38] <jtruelove_> it would just be nice if you could have SPI options returned but i get why you can't
+[23:36:04] <jtruelove_> on the thomas thing, i think you guys are discussing a common interface for reporting gauges, counters, and timers via the event bus
+[23:36:07] <jtruelove_> and also maybe directly
+[23:36:16] <temporalfox> we are discussing two things
+[23:36:19] <jtruelove_> which is what vertx-opentsdb does more or less
+[23:36:19] <temporalfox> 1/ what you said
+[23:36:41] <temporalfox> 2/ abbstract the hawkular spi implementation to be decoupled from hawkular
+[23:36:45] <temporalfox> and have hawkular only being a reporter
+[23:37:11] <temporalfox> so the generic SPI impl gather statistics and periodically flush them in hawkular using a rest client
+[23:37:20] <temporalfox> because these days many TSDB work this way
+[23:37:30] <temporalfox> hawkular, opentsdb, influxdb, etc...
+[23:37:35] <jtruelove_> yeah exactly
+[23:37:42] <temporalfox> that would allow to have in common this collecting spi code
+[23:37:43] <jtruelove_> some don't support gauges but other than that
+[23:37:56] <jtruelove_> and be smart hopefully about batching and things
+[23:37:59] <temporalfox> I think when you report you get generic statistics
+[23:38:11] <temporalfox> and then it's up to the reporter to take care of this :-
+[23:38:13] <temporalfox> :-)
+[23:38:37] <temporalfox> I think thomas wants also to make a persistent queue
+[23:38:47] <temporalfox> so if metric server is down
+[23:38:51] <temporalfox> metrics are stored there
+[23:38:54] <temporalfox> and queued
+[23:38:57] <temporalfox> until it comes back
+[23:39:36] <jtruelove_> interesting, could be good but could also be a pain in the ass
+[23:39:52] <temporalfox> I think this would be optional
+[23:39:52] <jtruelove_> depending on how long it would take data before purging
+[23:40:11] <temporalfox> but you can discuss that on vertx-dev if you are concerned
+[23:40:19] <jtruelove_> or popping longest in the queue data etc..
+[23:44:27] <jtruelove_> i'll try and engage on that thread