Differences

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

Link to this comparison view

irc:1436824800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[10:09:48] <​eli_>​ hi, could you help me please? Can i make dynamic handler(implmented function) in vert.x js?
 +
 +[10:17:50] <​eli_>​ What means a "​this"​ on vertx inside function?
 +
 +[12:12:08] <​msavy>​ hey temporalfox,​ apologies for prodding - but have you had any thoughts on this thread https://​groups.google.com/​forum/#​!topic/​vertx/​ZIpkBWYJtCc - i'm really keen to use your code generation in apiman'​s vert.x gateway
 +
 +[12:17:55] <​temporalfox>​ hi msavy sorry I haven'​t answered to you yet, I will answer in this thread soon
 +
 +[12:18:34] <​msavy>​ temporalfox:​ thank you very much, appreciate it!
 +
 +[12:18:46] <​temporalfox>​ msavy hold on
 +
 +[12:19:07] <​temporalfox>​ so you want to send buffers
 +
 +[12:19:14] <​temporalfox>​ I think we don't support vertx gen
 +
 +[12:19:44] <​temporalfox>​ becasue vertxgen does not understand Buffer natively
 +
 +[12:20:06] <​msavy>​ that's what i thought :-(. i was hoping you might have some alternative in @ProxyGen where you could generate an extra endpoint based upon the method name
 +
 +[12:20:28] <​temporalfox>​ I will think about something
 +
 +[12:20:38] <​temporalfox>​ actually that's purplefox_ that did the proxygen :-)
 +
 +[12:20:58] <​temporalfox>​ I did the rxjava gen
 +
 +[12:21:02] <​purplefox_>​ temporalfox:​ codegen does support buffer, the problem is with proxygen, as all proxy requests have to be serialized to json
 +
 +[12:21:04] <​temporalfox>​ I think the best way at the moment
 +
 +[12:21:12] <​temporalfox>​ might be to wrap it in json
 +
 +[12:21:27] <​msavy>​ in my existing implementations that's effectively what i do manually - let's say i have write(buffer),​ i have an additional endpoint "​a.b.c.d.writeBuffer"​ which is purely for the buffer
 +
 +[12:21:31] <​msavy>​ no json whatsoever
 +
 +[12:21:31] <​temporalfox>​ I mean codegen does not support buffer as a native type
 +
 +[12:21:37] <​temporalfox>​ or byte[]
 +
 +[12:21:45] <​purplefox_>​ it does support buffer
 +
 +[12:21:51] <​temporalfox>​ yes
 +
 +[12:22:01] <​purplefox_>​ buffer is marked as @VertxGen
 +
 +[12:22:05] <​temporalfox>​ I mean that it does support it as any codegen
 +
 +[12:22:09] <​temporalfox>​ it does not have a special handling
 +
 +[12:22:19] <​temporalfox>​ for such case
 +
 +[12:22:31] <​purplefox_>​ the issue is with proxygen and json serialisation nothing to do with codegen
 +
 +[12:22:35] <​temporalfox>​ indeed
 +
 +[12:22:37] <​temporalfox>​ as you said
 +
 +[12:23:10] <​msavy>​ purplefox_: i guess i was also thinking of it from an efficiency perspective it'd be nice to do those separately so you don't do a load of json serialization/​deserialization,​ right? special case where having an additional listener might be worth it?
 +
 +[12:24:11] <​msavy>​ i don't think it'd break the semantics of @ProxyGen, right?
 +
 +[12:25:11] <​purplefox_>​ sure. we serialize to json as that's the most interoperable (e.g. someone can easily call an endpoint by just sending messages) but alternative marshalling could be implemented
 +
 +[12:27:14] <​msavy>​ i was thinking that the other elements would still be JSON (in my example, '​head'​ and '​end'​ still arrive on the JSON channel), and only write(Buffer) is on its own '​binary only' channel.
 +
 +[12:27:36] <​msavy>​ i guess the alternative would be to use something like BSON, but i guess that'd still have more overhead than throwing the Buffer onto the wire
 +
 +[12:28:42] <​purplefox_>​ well.. you could encode the entire request as a single buffer and just send that. that would probably be most efficient
 +
 +[12:48:37] <​msavy>​ purplefox_: indeed, was just hoping to use temporalfox'​s proxy stuff as it's fantastic to have the annotated interfaces. i'll go and have a think :). thanks.
 +
 +[12:57:13] <​purplefox_>​ msavy: i know a little more about the proxy stuff as i wrote it, not temporalfox. but the idea of different marshalling has always been on the table
 +
 +[12:57:21] <​purplefox_>​ but you'd need to write a different template
 +
 +[12:58:51] <​purplefox_>​ maybe we could make the transcoder pluggable
 +
 +[12:59:24] <​purplefox_>​ then we could have different implementations - one that transcodes to json (i.e. the current one), another optimised one to buffer, etc
 +
 +[13:04:10] <​msavy>​ purplefox_: that's a cool idea
 +
 +[13:52:52] <​msavy>​ purplefox_: and i guess that could work on a hybrid basis, i.e. some of the methods in the same interface might use json, others might use some binary marshalling (or whatever)?
 +
 +[13:53:07] <​msavy>​ depending on what the optimal approach was
 +
 +[13:53:11] <​msavy>​ or do you think that's not practical
 +
 +[14:46:06] <​temporalfox>​ msavy the @ProxyGen interface could specify an encoder class, @ProxyGen(MyEncoder.class)
 +
 +[14:49:50] <​aesteve>​ hi everyone :)
 +
 +[14:50:04] <​aesteve>​ The Google Group is on fire lately :o
 +
 +[14:56:26] <​purplefox_>​ temporalfox:​ +1
 +
 +[14:57:04] <​purplefox_>​ aesteve: yes it's on fire, but a lot of the questions seem to be along the lines of "how do i set up a simple maven project"​ which is quite depressing
 +
 +[14:58:43] <​aesteve>​ some, yes but there are also real questions. Like "what happens when you call executeBlocking() from a worker thread",​ which I actually never thought about
 +
 +[14:59:17] <​purplefox_>​ i don't understand that question and the way it's posted seems rather confused
 +
 +[15:00:02] <​purplefox_>​ i asked for clarification twice on that one
 +
 +[15:00:44] <​aesteve>​ I'm far from being a thread expert so i don't have a clue about the dealock thing
 +
 +[15:01:09] <​purplefox_>​ i've actually no idea what he is talking about
 +
 +[15:01:20] <​aesteve>​ but the question I'm asking myself is : what happens when you call executeBlocking from a worker verticle
 +
 +[15:01:42] <​aesteve>​ (because that doesn'​t seem right to me, but if you actually do so, what happens ?)
 +
 +[15:01:42] <​purplefox_>​ temporalfox:​ aesteve: anyway why are you two here? Isn't today when you celebrate breaking into a prison, then chopping off heads of kings or something ? ;)
 +
 +[15:02:22] <​aesteve>​ actually the Bastille day was really a symbol iirc my history lessons
 +
 +[15:02:50] <​aesteve>​ like they went into the Bastille, there was like 3 or 4 poor prisonners nobody knew about
 +
 +[15:02:52] <​purplefox_>​ but it's a national holiday, no?
 +
 +[15:02:57] <​aesteve>​ (and no guard)
 +
 +[15:03:11] <​aesteve>​ yes it's holiday :)
 +
 +[15:03:24] <​temporalfox>​ my wife and myself have been renovating a room of our apparement since saturday :-)
 +
 +[15:03:31] <​aesteve>​ but remember, vert.x isn't my job :)
 +
 +[15:04:26] <​aesteve>​ tough work with the current weather
 +
 +[15:05:03] <​purplefox_>​ brb
 +
 +[15:07:33] <​aesteve>​ purplefox_: for the question, the way I understand it is just : from a worker verticle, your code is already running in a thread from the worker pool, then if from this code you call executeBlocking,​ are you using another thread from the worker pool, or the same ?
 +
 +[15:18:47] <​purplefox_>​ aesteve: in a worker verticle there are no guarantees of which thread executes it
 +
 +[15:19:05] <​purplefox_>​ other than (in a standard worker) it's not executed by more than one thread concurrently
 +
 +[15:19:56] <​purplefox_>​ executeBlocking simply execcutes the block using a worker thread
 +
 +[15:22:26] <​purplefox_>​ msavy: temporalfox:​ https://​github.com/​vert-x3/​vertx-service-proxy/​issues/​17
 +
 +[15:22:45] <​temporalfox>​ +1 purplefox_
 +
 +[15:43:21] <​msavy>​ purplefox_: temporalfox:​ thanks, guys!
 +
 +[15:43:41] <​DP2015>​ whats the differnece between ​  ​vertx-mysql-postgresql-client, ​    SQL common ​ and   JDBC client
 +
 +[15:44:05] <​DP2015>​ i want to connect to postgres?
 +
 +[20:39:59] <​jtruelove>​ yeah and i checked the code
 +
 +[20:40:05] <​jtruelove>​ https://​www.irccloud.com/​pastebin/​8wPVAl5y/​
 +
 +[20:40:12] <​jtruelove>​ it is indeed the case
 +
 +[20:40:19] <​jtruelove>​ feels odd
 +
 +[21:17:40] <​AlexLehm>​ actually its documented like this https://​github.com/​vert-x3/​vertx-web/​blob/​master/​src/​main/​java/​io/​vertx/​ext/​web/​Route.java#​L98
 +
 +[21:19:01] <​jtruelove>​ yeah that is the block of code i posted above
 +
 +[21:19:31] <​jtruelove>​ it's just odd to get the same behavior you have to create duplicate routes
 +
 +[23:13:08] <​voidDotClass>​ http://​blog.lumension.com/​10334/​java-zero-day/​