Differences

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

@@ Line 1: / Line 1: @@
+[00:00:24] <jtruelove> probably the one it's going to set on the vertx instance
+[00:01:19] <jtruelove> the problem is i initialize the publisher in the ScheduleMetrics class whose constructor just takes options and vertx
+[00:01:38] <temporal_> I think it's not est case
+[00:01:47] <temporal_> can you open an issue for it ?
+[00:02:07] <jtruelove> yeah and i can just disable this code for the release until then
+[00:02:20] <jtruelove> i mean i could dig in and look i just don't have the time right now
+[00:03:48] <temporal_> just open an issue ^^
+[00:03:54] <temporal_> so we remember
+[00:58:36] <jtruelove> yes i will and give you gist because i'm a classy guy
+[01:41:58] *** ChanServ sets mode: +o purplefox
+[01:49:38] <jtruelove> temporal_ maybe this is by design so the eventBus createMetrics callback takes an eventBus object
+[01:49:57] <jtruelove> AND that just so happens to be the same object that's set on the vertx instance later
+[01:50:27] <jtruelove> the thing that makes this a 'pain' is then you need ScheduleMetrics to have multiple constructors
+[01:57:38] <jtruelove> the rest of them just need vertx, so what is your opinion
+[02:35:00] <nkhanna> Is there any reason for the existence of io.vertx.rxjava.core.buffer.Buffer? A quick glance through the code didn[unknown:rsquo]t turn up any added RX functionality.
+[02:35:37] <nkhanna> And it doesnt even implement toString like the original io.vertx.core.buffer.Buffer that returns the buffer contents
+[10:18:01] *** ChanServ sets mode: +o purplefox
+[10:27:45] *** ChanServ sets mode: +o temporalfox
+[11:18:33] <alvaro_sanchez> Hi guys, I have an external module offering some persistence methods. What would be The Vert.x Way(tm) to integrate it in a Vert.x application? Exposing it through the event bus?
+[11:21:26] <cescoffier> alvaro_sanchez: yes, you can do it by exposing a service on the event bus
+[11:28:06] <alvaro_sanchez> Sweet. So basically the module brings this interface:
+[11:28:10] <alvaro_sanchez> interface TeamRepository {
+[11:28:10] <alvaro_sanchez>     void init()
+[11:28:10] <alvaro_sanchez>     void save(Team team)
+[11:28:10] <alvaro_sanchez>     Team findbyName(String name)
+[11:28:11] <alvaro_sanchez>     List<Team> list()
+[11:28:11] <alvaro_sanchez>     void update(Team team)
+[11:28:11] <alvaro_sanchez>     void delete(Team team)
+[11:28:11] <alvaro_sanchez> }
+[11:28:16] <alvaro_sanchez> Fuck.
+[11:28:41] <alvaro_sanchez> Code looks horrible here
+[11:29:28] <alvaro_sanchez> Anyway, that's few methods. How should I expose them? One EB address per method? or a generic one where the method is part of the JSON?
+[11:29:53] <cescoffier> look at the service-proxy: https://github.com/vert-x3/vertx-examples/tree/master/service-proxy-examples
+[11:30:12] <cescoffier> you annotate your interface, and it generates all clients
+[11:32:17] <alvaro_sanchez> AWESOME. Looks like what I need
+[11:32:52] <alvaro_sanchez> I would appreciate a "reference sample application", or at least one for Vert.x Web
+[11:33:40] <alvaro_sanchez> There are many examples and they are a lot useful, but they feel disconnected to me, and when you want to put all the pieces together, a recommended approach would help
+[11:34:10] <alvaro_sanchez> Just my opinion though
+[11:35:41] <cescoffier> actually, I'm going to do that in a blog post of the "introduction to vert.x" series.
+[11:36:17] <cescoffier> it's exactly what you do more or less, extract a "persistence" service dealing with a database, and consuming it from a vert.x web app
+[11:37:08] <alvaro_sanchez> Great. I wish I would have seen it before :)
+[16:07:03] <rajith> purplefox: hey Tim
+[16:08:30] <purplefox> hi rajith
+[16:08:39] <rajith> purplefox: u are back
+[16:09:08] <rajith> purplefox: I have your examples ready. Give me a few mins to work out a merge conflict and push it up stream.
+[16:09:34] <purplefox> rajdavies: did you see the PR from hiram?
+[16:10:12] <purplefox> it looks pretty cool. i haven't had much chance too look in detail today as I've been off sick most of the day
+[16:11:34] <rajith> purplefox: looking into it
+[16:11:47] <chirino> purplefox: you liked the bonus server example eh :)
+[16:11:50] <rajith> purplefox: give me 15 mins to get back to you
+[16:12:13] <purplefox> chirino: that was a nice touch :)
+[16:13:57] <purplefox> it looks like it's along the right lines
+[16:14:20] <purplefox> i would also be cool to get rajith feedback as you guys seem to be doing similar things
+[16:15:12] <purplefox> the goal appears the same though - to provide a simple java async api over proton
+[16:15:19] <purplefox> which could come in useful in lots of places imho
+[16:16:07] <chirino> ya
+[16:16:23] <rajith> chirino: I like it .. it's actually not too different from what I have done
+[16:16:29] <chirino> cool
+[16:16:53] <rajith> purplefox: chirino + on the asycn API over proton. I had to do that as proton was a PIA to work with
+[16:16:59] <chirino> so I did not look into any of shutdown bits
+[16:17:22] <chirino> and stuff like detach
+[16:17:36] <rajith> purplefox: the merge conflicts came from the code formatting u did :p ... I forgot to pull before I made the changes :(
+[16:17:44] <chirino> :(
+[16:17:44] <rajith> purplefox: should be sorted out momentarily
+[16:18:44] <chirino> also the whole decoding/encoding messages needs to be improved to handle large message and fragmented messages.
+[16:18:56] <chirino> still lots of work to make it good.
+[16:19:13] <rajdavies> chirino - think that would look cool in fabric8mq ;)
+[16:22:48] <chirino> purplefox: one little smelly bit I found was the need to do: the flush() at https://github.com/purplefox/vertx-proton/blob/master/src/main/java/io/vertx/proton/HelloWorldServer.java#L90
+[16:24:06] <chirino> purplefox: perhaps vertx could give me a way for connection to know when timer tasks finish executing so they could auto flush
+[16:24:56] <purplefox> what's the purpose of the flush?
+[16:25:38] <chirino> stuff done against the proton api buffers up (is all async) flush takes pending bytes from the proton api and pushes then into the vert.x socket
+[16:26:10] <chirino> did not need a flush in other places because with flush() after the proton transport triggers callbacks
+[16:26:24] <chirino> s/with/we
+[16:27:27] <purplefox> so you need to flush after sending each message?
+[16:27:47] <purplefox> not sure I understand what you mean about timers
+[16:27:48] <chirino> well depends how much you want to batch.
+[16:28:20] <chirino> I guess we could flush after ever actions that trigger data to be written
+[16:28:32] <purplefox> well... the vert.x connection wil itself batch so batching on the proton stuff is not really going to add anything
+[16:28:55] <purplefox> so we should probably just flush after each message
+[16:29:01] <chirino> so a write on proton will be delayed a bit?
+[16:29:09] <chirino> sory
+[16:29:17] <chirino> a write to vert.x is delayed?
+[16:29:22] <purplefox> tbh, adding stuff to proton buffers only to then immediately remove them and write to the vert.x connection seems an unnecessary overhead
+[16:29:33] <purplefox> not sure i really understand all that stuff
+[16:29:45] <chirino> so proton is kinda like the SSL engine api java has
+[16:30:52] <chirino> you use the API side of it, and then it has the input/output buffers that you have to push/pull to the network
+[16:31:06] <purplefox> the way the batching works in vert.x (actually netty)
+[16:31:08] <chirino> would have been nice if you could give it your own buffers
+[16:31:18] <chirino> but that's not how it's built
+[16:31:31] <purplefox> is you write to the connection
+[16:31:41] <purplefox> and that won't necessarily cause a write to the socket
+[16:31:55] <purplefox> but when the selector is ready for writes it will then actually write it
+[16:32:08] <purplefox> this is more optimal than flushing every time
+[16:32:18] <chirino> yeah that sounds good.
+[16:32:33] <chirino> so I guess we just need to call flush in more places :)
+[16:32:39] <purplefox> yeah i guess :)
+[16:32:46] <chirino> like after every open, and send etc.
+[16:33:15] <purplefox> makes sense
+[16:37:00] <chirino> does vert.x copy buffers when it moves data between NetSockets and netty?
+[16:41:31] <rajith> temporalfox: the vertx-amqp-service master doesn't compile. Maybe something changed btw your last comment and now?
+[16:42:15] <temporalfox> rajith I don't kno
+[16:42:51] <rajith> temporalfox: I think the culprit is LoggerManager package was changed :p
+[16:43:13] <rajith> temporalfox: I just changed it ... but wanted to know if LoggerManager is deprecrated or not
+[16:43:30] <rajith> temporalfox: before it was import io.vertx.core.logging.LoggerFactory; now it's under an impl directory
+[16:43:48] <temporalfox> I believe it was never really part of public api
+[16:43:56] <temporalfox> I don't know who moved it
+[16:44:04] <temporalfox> I haven't keep tracked of that change
+[16:45:16] <rajith> temporalfox: thats ok .. no worries. I just changed to the new package name in my import
+[16:46:28] <rajith> temporalfox: codegen for AMQPService is again broken ... the error doesn't say where the error is
+[16:47:06] <rajith> temporalfox: purplefox btw I wonder there is a way to do a night;y build .. that way I can keep track of the project changes and attend to issues faster.
+[16:50:12] <rajith> purplefox: btw the lack of a proper user friendly java API for proton is the main reason my AMQP examples are in python
+[16:51:05] <AlexLehm> purplefox: can I ask you about the status of my BZ480001 ticket? It seems I have not properly explained why this is a bug
+[16:53:55] <chirino> purplefox: do you guys have an abstraction in vertx for NetSockets and WebSockets?
+[16:56:06] <chirino> Since AMQP can be used over websockets too would be nice if there was something that we could use instead of a NetSocket
+[17:04:07] <jtruelove> temporalfox a couple questions on SPI 1) the event bus reporting seems kinda chatty i'm seeing all kinds of metrics for numbered topics any easy way to filter those? 2) on the http client/server metrics i get metrics on both of them for the same request so say someone does a GET to /foo i see that data reported in the client endpoint and the server
+[17:04:47] <temporalfox> jtruelove hi
+[17:05:05] <temporalfox> jtruelove it is up to you to make this configurable
+[17:05:26] <temporalfox> jtruelove in dropwizard there is possibility to filter the http reporting by matching URIs
+[17:05:36] <temporalfox> jtruelove one reason of a consolidaed project
+[17:05:49] <temporalfox> would be to have the same config for dropwizard, hawkular or opentsdb
+[17:06:15] <jtruelove> yeah i mean i could build all sorts of stuff in but i was just going with the lightweight integration
+[17:06:15] <temporalfox> jtruelove one thing  Iwant to do actually is a setEnabled(true/false) on Measured interface
+[17:06:21] <temporalfox> to turn of specific reporting parts
+[17:06:26] <rajith> chirino: did you hear about gordons work? his pure java script client would support websockets .
+[17:06:36] <jtruelove> i just setup flags in mine on the options object
+[17:07:02] <jtruelove> how do i filter the system event bus messages though?
+[17:07:17] <jtruelove> topics like 20, 21, 30 etc.. just random numbers
+[17:07:30] <temporalfox> what do you mean ?
+[17:07:47] <temporalfox> some topics are for netsockets
+[17:07:54] <temporalfox> I mean address
+[17:08:00] <jtruelove> well when i have event bus reporting on i'm seeing message counts for number topics
+[17:08:05] <temporalfox> when a netsocket is created it is registered as an event bus consumer
+[17:08:09] <jtruelove> that i'm not sending
+[17:08:19] <temporalfox> I think it's the netsocket registration
+[17:08:31] <temporalfox> I would like to have a flag for such things maybe
+[17:08:50] <jtruelove> that will just result in a ton of noise the numbered topics don't have a lot of meaning
+[17:09:02] <temporalfox> jtruelove only registration
+[17:09:05] <temporalfox> they don't send messages
+[17:09:12] <temporalfox> (but someone can if it likes)
+[17:09:23] <jtruelove> hmm i'm seeing message counts come in
+[17:09:33] <temporalfox> so soomething is sending messages :-)
+[17:09:40] <temporalfox> can you print a stacktrace of the sender ?
+[17:09:58] <jtruelove> right but i think it must be at the framework level because my unit / integration test is not
+[17:10:03] <jtruelove> other than on a named topic
+[17:10:07] <temporalfox> ok
+[17:10:17] <temporalfox> how is going your implemenation btw ?
+[17:10:21] <temporalfox> sounds like you are doing good progress
+[17:10:39] <jtruelove> it's pretty much done i just came across a few of these things when doing the final testing
+[17:10:54] <temporalfox> ok
+[17:11:06] <jtruelove> i don't quite get why it logs on both client and server http for 1 request
+[17:11:12] <temporalfox> do you mind in the future perhaps to merge this in a consolidated metrics projects along with dropwizard and hawkular ?
+[17:11:15] <temporalfox> like after 3.2
+[17:11:34] <temporalfox> jtruelove if you are using vertx client it's normal to get it reported
+[17:11:47] <temporalfox> why would it be odd ?
+[17:12:32] <jtruelove> i would expect one to show incoming requests and one to show out bound requests from the server
+[17:13:02] <jtruelove> why measure the same info two places
+[17:13:30] <jtruelove> it looks the exact same bytes read/written and time
+[17:14:20] <alvaro_sanchez> purplefox temporalfox pmlopes cescoffier this is the code I'll be using in a presentation about Vert.x. Any feedback would be appreciated: https://github.com/alvarosanchez/vertx-vs-ratpack/tree/master/vertx
+[17:16:56] <temporalfox> alvaro_sanchez are there slides ?
+[17:17:34] <alvaro_sanchez> temporalfox:there will be, they are in progress
+[17:18:06] <alvaro_sanchez> first of all I wanted to make sure that the approach for code and tests is the best one could follow
+[17:18:08] <temporalfox> alvaro_sanchez I've seen the ratpack DSL for writing groovy async apps
+[17:18:11] <temporalfox> it looks interesting
+[17:18:30] <temporalfox> alvaro_sanchez I'm not good at performance thing :-)
+[17:18:32] <purplefox> alvaro_sanchez: how would you like us to provide feedback?
+[17:18:39] <temporalfox> however I can help you for the functionnal style
+[17:19:15] <alvaro_sanchez> I'm interested in your feedback about the code I've used in the vertx module, to know if that's the best way to do it
+[17:19:24] <alvaro_sanchez> the 2 verticles and the test
+[17:19:39] <purplefox> alvaro_sanchez: cool, but how? here? somewhere else?
+[17:20:06] <temporalfox> alvaro_sanchez I believe it could be improved by using a service proxy instead of the event bus directly
+[17:20:11] <alvaro_sanchez> Whichever way you prefer: you can send a PR, or just write here and I'll apply the changes
+[17:20:14] <temporalfox> for the TeamRepository
+[17:20:28] <temporalfox> but it would need change maybe also in the TeamRepository
+[17:20:32] <temporalfox> I can have a look maybe
+[17:21:01] <purplefox> alvaro_sanchez: the way you're doing the jdbc is quite unusual, it would be simpler to just use the jdbc client directly from the web verticle (less moving parts)
+[17:21:05] <alvaro_sanchez> I had a look at it, but it's not straightforward to have the codegen working with Gradle
+[17:21:26] <temporalfox> alvaro_sanchez good point, we should do perhaps something for Gradle codegen
+[17:21:39] <temporalfox> I can certainly help you at least on that
+[17:21:46] <purplefox> i don't recommend using the event bus or service proxy that's really an advanced use case
+[17:21:52] <temporalfox> I agree with you
+[17:22:06] <purplefox> if you just want to show a simple webapp talking to a database it's much simpler
+[17:22:21] <temporalfox> it would be wrapped directly in the TeamRepo
+[17:22:23] <purplefox> you don't need two verticles just one will do
+[17:22:46] <alvaro_sanchez> it was my first thought, but it felt too easy :)
+[17:22:54] <rajith> purplefox: sent you the examples and copied chirino on it
+[17:23:06] <purplefox> alvaro_sanchez: you like extra complexity? ;)
+[17:23:10] <temporalfox> alvaro_sanchez don't look for overcomplicated things :-)
+[17:23:32] <purplefox> surely an example that does it with less moving parts is better :)
+[17:23:51] <alvaro_sanchez> well, the event bus is one of the clear advantages of Vert.x over Ratpack. Not showing it wouldn't be fair
+[17:24:01] <rajith> purplefox: we should aim to have a common code base for the AMQP stuff so we reuse a more tested version. We should also borrow/change ideas from chirino
+[17:24:20] <alvaro_sanchez> Also, I want the audience to get an idea about how would it feel to integrate an existing business service
+[17:24:22] <purplefox> there's no point in showing the event bus if it makes no sense for a particular example
+[17:25:32] <alvaro_sanchez> so you suggest making the calls directly and wrapping them with blocking calls?
+[17:25:49] <purplefox> no, vert.x provides a non blocking jdbc client
+[17:26:08] <purplefox> here's a groovy example:
+[17:26:08] <purplefox> https://github.com/vert-x3/vertx-examples/blob/master/jdbc-examples/src/main/groovy/io/vertx/example/jdbc/simple/jdbc_example.groovy
+[17:26:45] <alvaro_sanchez> but in my example, "teams-core" is shared for both implementations
+[17:26:47] <purplefox> you can even use vertx-sync and then you lose all the callbacks:
+[17:26:48] <purplefox> https://github.com/vert-x3/vertx-examples/blob/master/sync-examples/src/main/java/io/vertx/example/sync/jdbc/Client.java
+[17:27:10] <alvaro_sanchez> and "teams-core" is vertx (or ratpack) agnostic
+[17:27:54] <purplefox> yeah, but no-one would use that in a real vert.x application
+[17:28:02] <purplefox> as we provide async database capabilities
+[17:28:11] <purplefox> so you're example won't really represent a real Vert.x app
+[17:28:38] <purplefox> it would basically be very "un-vert.x-y"
+[17:28:58] <alvaro_sanchez> okay, I'll remove the shared module then
+[17:29:18] <alvaro_sanchez> although I liked the idea of having a common service for both implementations
+[17:29:36] <alvaro_sanchez> but yeah, not a fair use case
+[17:29:43] <purplefox> i'm, not sure it really makes sense as your shared module is blocking and vert.x is all about non-blocking
+[17:30:19] <purplefox> what would be really cool, and really simple imho, would be if you used vert.x web for the REST stuff and vertx-sync for the database stuff
+[17:30:32] <purplefox> then you'd lose the callbacks too and it would be much less verbose
+[17:30:38] <alvaro_sanchez> I did use vert.x web, didn't I?
+[17:30:42] <purplefox> yes
+[17:31:49] <purplefox> and actually java would be a bit less verbose than grooovy as you wouldn't need to type the closure params as Handler<Asyncresult<>>
+[17:32:24] <alvaro_sanchez> you don't need in groovy either, that's just a personal preference
+[17:33:54] <alvaro_sanchez> I can't use vertx-sync with groovy can I?
+[17:34:50] <purplefox> unfortunatelt no
+[17:35:06] <purplefox> it's java only
+[17:36:34] <alvaro_sanchez> alright, I'll use at least vert.x async jdbc client
+[17:37:02] <alvaro_sanchez> will write here once I have another version ready to be checked
+[17:37:12] <alvaro_sanchez> and thanks for the feedback so far :)
+[17:37:54] <alvaro_sanchez> btw, the test looks good? are any of you aware of the possibility to use spock?
+[17:49:39] <jtruelove> temporalfox here's some of the sample data output for the event bus
+[17:49:48] <jtruelove> https://www.irccloud.com/pastebin/poFe1EK0/
+[17:50:23] <jtruelove> you can see the one named topic i'm sending there
+[17:50:32] <jtruelove> then a bunch of stuff that must be at the framework level
+[17:51:57] <jtruelove> here's the double metrics on server and client i'm talking about
+[17:52:07] <jtruelove> https://www.irccloud.com/pastebin/8kog6HZw/
+[17:54:38] <temporalfox> is the vertx instance the same host/client
+[17:54:39] <temporalfox> ?
+[17:55:44] <jtruelove> yeah in the unit tests
+[17:55:56] <jtruelove> so yeah you're right i'm dumb
+[17:56:15] <jtruelove> :)
+[17:56:27] <jtruelove> BUT the event bus business is still really odd
+[17:56:36] <jtruelove> and i don't know how to filter it out
+[18:00:20] <jtruelove> here's the basic impl i settled on -> http://review.cyanogenmod.org/#/c/111591/ need to update the README still
+[18:01:35] <temporalfox> so in eventbus, the 12 lines are events you cannot figure out the provenance ?
+[18:01:57] <temporalfox> what means "put event_bus.1.sent 1445356090148 1 host=test.host.com" ?
+[18:07:11] <jtruelove> that is how you format events to opentsdb
+[18:07:56] <jtruelove> it's  [command] [name] [timestamp] [value] [tags list]
+[18:08:17] <jtruelove> so that event_bus.1 is some topic being sent on the bus
+[18:08:25] <jtruelove> but i'm not sure by whom
+[18:08:59] <temporalfox> ah ok
+[18:09:20] <temporalfox> can you put break points in your code to see ?
+[18:10:10] <jtruelove> yeah i thought you might know off hand give me a second
+[18:10:30] <melvinross> is the official process for getting edits on the vertx awesome github page just to submit an issue on github?
+[18:11:02] <temporalfox> melvinross yes I think it's more or less how we do
+[18:11:26] <melvinross> thanks
+[18:11:34] <temporalfox> jtruelove hard to tell without looking at your code and setup :-)
+[18:16:39] <jtruelove> temporalfox looks like it's replies
+[18:17:03] <jtruelove> replies appear to have an implicit monotonically increasing number topic
+[18:17:19] <chirino> purplefox, temporalfox: do you guys have an abstraction in vertx for NetSockets and WebSockets?
+[18:19:01] <jtruelove> temporalfox so if you have a reply handler on a message it gets a numbered topic then when you reply to the message it goes to that topic
+[18:19:06] <chirino> would have been nice if they both implemented a common Socket interface
+[18:19:21] <jtruelove> so anyone using replies would see that but doesn't seem to have much meaning
+[18:19:23] <temporalfox> jtruelove yes it creates a temporary reply address
+[18:19:34] <temporalfox> but you know when it's a reply though
+[18:19:48] <temporalfox> at some point I suggested to have naming pattern for addresses
+[18:19:57] <temporalfox> like "reply." for replies
+[18:20:10] <temporalfox> or "vertx." prefix
+[18:20:13] <temporalfox> for netsocket
+[18:20:31] <temporalfox> chirino indeed right now we force to use the same kind off
+[18:21:01] <jtruelove> temporalfox based on the methods how do i know it's a reply?
+[18:21:16] <temporalfox> chirino but WriteStream<Buffer> / ReadStream<Buffer> is common super interface for sending/write buffers
+[18:21:28] <jtruelove> this is one of the signatures -> messageSent(String address, boolean publish, boolean local, boolean remote)
+[18:21:37] <temporalfox> jtruelove ah yes you are right
+[18:21:42] <temporalfox> hence my naming suggestion :-)
+[18:21:46] <jtruelove> lol
+[18:21:47] <chirino> temporalfox: in a project I ended up having to do wrapper objects to abstract it out
+[18:21:49] <chirino> https://github.com/chirino/fabric8/blob/1.2.0.redhat-6-2-x-patch/gateway/gateway-core/src/main/java/io/fabric8/gateway/SocketWrapper.java
+[18:21:55] <jtruelove> well at least i'm not crazy
+[18:22:07] <chirino> but I think it would have been cleaner if there was a common interface for the 2
+[18:22:08] <jtruelove> shall i file a bug?
+[18:22:42] <temporalfox> jtruelove it's more an enhancement :-)
+[18:22:50] <temporalfox> so a boolean that says wether or not it's a reply ?
+[18:22:56] <jtruelove> yeah
+[18:22:57] <temporalfox> or a naming scheme
+[18:23:03] <jtruelove> either
+[18:23:08] <temporalfox> ok
+[18:23:18] <jtruelove> well it makes the eventbus SPI so noisy and adds data that is hard to use
+[18:23:19] <rajith> temporalfox: ping
+[18:23:24] <temporalfox> jtruelove you can create on in vert-x3/issues
+[18:23:35] <jtruelove> yeah i can with the other bug
+[18:24:01] <jtruelove> i can look at making the change if i get some time
+[18:24:20] <jtruelove> i can do something dirty in the mean time like ignore integer topics
+[18:24:52] <chirino> @temporalfox: sometimes you want to even start a an SSL session on an existing NetSocket and you still want a Socket abstraction
+[18:24:56] <chirino> kinda like: https://github.com/chirino/fabric8/blob/1.2.0.redhat-6-2-x-patch/gateway/gateway-core/src/main/java/io/fabric8/gateway/handlers/detecting/protocol/ssl/SslSocketWrapper.java#L393
+[18:26:26] <chirino> purplefox: we could probably even create Socket abstractions over AMQP
+[19:10:21] <jtruelove> temporalfox https://bugs.eclipse.org/bugs/show_bug.cgi?id=480242 https://bugs.eclipse.org/bugs/show_bug.cgi?id=480240
+[19:10:26] <jtruelove> the 2 issues we discussed
+[19:20:37] <chirino> temporalfox: purplefox: this was what I was thinking of that would make life a little easier for clients that can work on net or web sockets: https://github.com/eclipse/vert.x/pull/1182
+[21:15:44] *** ChanServ sets mode: +o temporalfox
+[21:37:21] <jtruelove> purplefox temporalfox what do you guys think about allowing AbstractVerticle to support a method getOptions that way you can return VertxOptions from it enabling specific say SPI impls?
+[21:37:42] <jtruelove> that way you wouldn't have to write a wrapper verticle and could still use the default starter
+[21:38:10] <temporalfox> jtruelove chicken egg problem
+[21:38:23] <jtruelove> it has to have it to call it?
+[21:38:36] <temporalfox> vertx deploys verticles
+[21:38:43] <temporalfox> and it needs options to create vertx
+[21:38:47] <temporalfox> what is your use case ?
+[21:38:50] <jtruelove> right
+[21:39:08] <jtruelove> well we used to be able to write our servers just extending AbstractVerticle
+[21:39:25] <jtruelove> now we have to make that a separate class that then loads vertx with options
+[21:39:35] <jtruelove> like you do in CLI to get in the opentsdb SPI impl
+[21:39:45] <jtruelove> just makes it more complicated now
+[21:42:22] <temporalfox> you can pass vertx options in CLI
+[21:42:38] <temporalfox> using proper escaping :-)
+[21:43:22] <temporalfox> perhpas you can have a subclass of AbstractVerticle
+[21:43:26] <temporalfox> tha provides them
+[21:43:33] <temporalfox> with a method runInVertx()
+[21:43:35] <temporalfox> that does
+[21:43:52] <temporalfox> Vertx.vertx(getOptions()).deployVerticle(this);
+[21:55:03] <jtruelove> yeah you just end up creating another vertx event loop there it would appear
+[22:24:56] <temporalfox> jtruelove I meant that you launch it without a prior vertx before
+[22:25:03] <temporalfox> new MyVerticle().runInVertx()
+[22:25:27] <temporalfox> anyway not sure how you want to run it
+[22:58:06] <jtruelove> yeah right now we run it with something like this via a shadowJar
+[22:58:20] <jtruelove> https://www.irccloud.com/pastebin/XLskwC68/
+[22:58:33] <jtruelove> where server extends AbstractVerticle
+[23:43:43] <AlexLehm> purplefox: if you have time, could you please take a look at my comment for the PR1178? This small bug breaks the timer execution and it would be easier to fix that instead of hacking the tests that use a timer in my modudle
+[23:45:19] <AlexLehm> either I am not explaining properly why this is a bug or the fix is not clear, I am not sure