[00:05:18] * ChanServ sets mode: +o temporalfox [00:36:16] <stillwater> I was trying that [00:36:20] <stillwater> initially [00:36:47] <stillwater> created a RxHelper.observableHandler() [00:37:17] <stillwater> and set that handler on the request().uploadHandler [00:37:30] <stillwater> in hopes that I could later subscribe to it [00:37:52] <stillwater> and use a pump to stream the content [00:38:45] <stillwater> but the readerStream that is my HttpServerFileUpload seems to have zero bytes in this case [00:39:10] <stillwater> even though I see the chunks being decoded in the Netty Multipart decoder [00:50:59] <AlexLehm> i have not actually used that i have to admit, but it should work [00:51:05] <AlexLehm> not sure about the rx stuff [04:47:28] * ChanServ sets mode: +o purplefox
[08:57:15] * ChanServ sets mode: +o purplefox [09:33:52] * ChanServ sets mode: +o temporalfox
[10:45:56] <temporalfox> pmlopes hi
[11:45:42] <pmlopes> hi
[12:54:09] <qerub> I[unknown:rsquo]m a bit confused by JDBCExample.java. Isn[unknown:rsquo]t the error handling way too simplistic? Shouldn[unknown:rsquo]t the connection be closed in more cases? Why isn[unknown:rsquo]t the the result from the second execute and the query checked?
[12:59:11] <purplefox> qerub: thanks. pls add a github issue against vertx-examples. btw, you might prefer the equivalent example in the vertx-sync examples
[14:23:24] <qerub> purplefox: Thanks, I will.
[14:25:05] <qerub> purplefox: Do you folks consider vertex-sync/quasar production-ready?
[14:37:57] <purplefox> qerub: it seems pretty solid but quasar is still pre 1.0. having said that not sure you can read too much into a version number (node.js was pre 1.0 for a long time(
[14:38:07] <purplefox> it might be worth asking the quasar folks
[14:45:17] <danlin> Last commit message for tag 3.1.0 is “Releasing 3.2.0”. Take it this is just typo? https://github.com/eclipse/vert.x/tree/3.1.0
[15:49:44] <gokl> Hi, do HttpClient response handlers run on the eventloop of the verticle where the request has been created?
[15:53:03] <gokl> Im asking because i see the handlers beeing run on different threads for different requests which causes race conditions in my implementation.
[18:02:14] <gemmellr> chirino_m: I had noticed the small credit window on the benchmark, was planning on mentioning it…I might not have set it quite that high ;)
[18:02:58] <gemmellr> chirino_m: raised a new PR with some fixes around the 'default sender' stuff
[18:03:52] <chirino_m> :)
[18:04:04] <gemmellr> chirino_m: in doing so, i kind of wonder about the API there with the send methods on the connection…
[18:05:19] <gemmellr> if you use the send methods you cant be sure the session or sender ever opens, or whether you get credit once it does, or adjust the QOS before it opens (rendering the delivered callback a bit useless if you don't), etc
[18:08:42] <gemmellr> streamlining creation of a session with an anonymous producer in it might be useful…but im inclined to think it should be an explicit operation and you get the sender (or some wrapper) back so you just treat it like a sender created the longer route of creating a session etc
[18:10:05] <chirino_m> gemmellr: yeah
[18:10:27] <chirino_m> you really can't flow control on it either.
[18:10:35] <chirino_m> so it really is a bit limiting
[18:10:50] <chirino_m> I agree I'm mostly concerned about handling the failure cases tho
[18:11:27] <chirino_m> I guess if a failure occurs, we could give em a delivery with a failure disposition right?
[18:11:51] <chirino_m> as in session or link open failure.
[18:13:31] <chirino_m> so if we don't get credit, I think it's ok to ignore. the send will queue up on the sender side.
[18:13:40] <chirino_m> we could get credit later afterall
[18:13:52] <gemmellr> yeah, those too…for the link open case thats one of the reasons i think the explicit operation is better, since link creation failure is actually rather complicated…
[18:14:51] <chirino_m> I was hoping we can keep the simple send as AMQP noobs might get scared of all this session/link stuff :)
[18:14:59] <gemmellr> it could yes…but it might never. The sender objects at least cover that with the 'is full' and 'callback' methods
[18:15:39] <chirino_m> we could also just expose the getDefaultSender() objects
[18:15:42] <chirino_m> methods
[18:15:57] <chirino_m> for folks who what to double check :)
[18:16:04] <gemmellr> i think we can keep a simple send…but im not sure it should be quite that simple…it would for example fail against 3 of the 5 brokers/others Im familiar with :)
[18:16:22] <chirino_m> I got a feeling, users will operate against a known system where the simple send will either work or not work.
[18:17:21] <chirino_m> as long as we don't silently fail, on some of those systems I think we are ok.
[18:17:39] <chirino_m> better if we fail with a decent error message
[18:18:31] <gemmellr> I dont think createDefaultSender() for example is that scary, rather than e.g exposing the getter…otherwise, still need to figure out thinks like the QOS..right now it cant be set, and i think it defaults to pre-setled.. but there is that delivered callback on one method
[18:23:50] <rajith> gemmellr: chirino_m hey guys if you update anything pls let me know so I can pull from the latest … also could you put some notes on the README or keep the examples up to date when you do API changes ?
[18:25:19] <rajith> gemmellr: chirino_m I will bug Julien tmr to hook us with the CI … that way we can make sure the team gets notified of any changes ..
[18:30:11] * ChanServ sets mode: +o temporalfox [18:32:24] <gemmellr> rajith: yeah any changes would be reflected in the examples [18:37:14] <rajith> gemmellr: thx [18:38:21] <gemmellr> rajith: based on what you said yesterday i dont think you are even using the bit we were just discussing anyway [19:03:55] <rajith> gemmellr_afk: yea [19:04:01] <rajith> gemmellr_afk: I might soon [20:20:44] * ChanServ sets mode: +o purplefox
[22:07:48] *** ChanServ sets mode: +o purplefox