This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[07:18:32] <anargund> Vertx.executeBlocking has parameter ordered. By default it is set to true, but would't you expect default value of this should be false since if you are trying to execute something in background thread you would expect it to execute it parallel?

[07:34:22] <myghty> hi

[07:35:55] <anargund> hi

[07:36:04] <myghty> anargund: this behaviour describes what happens if you call that multiple times

[07:36:16] <myghty> so e.g. you have a webserver running

[07:36:22] <myghty> which wants to write something in the database

[07:36:33] <myghty> and for each request you call “execute blocking something”

[07:36:55] <myghty> if ordered is true, each of those calls will be executed as they arrive

[07:37:13] <myghty> if you don't care about ordering because you think all of these calls can be handled independently

[07:37:19] <myghty> then you set ordered to false

[07:49:31] <myghty> anargund: does that answer your question?

[08:14:03] <myghty> temporalfox: u there? :)

[08:14:44] <myghty> do you know, what the exact difference between context.getBody() and context.request.getBodyhandler is? I mean: which one should I use if I wanna access the body of an incoming request?

[08:20:23] <pmlopes> @mighty you should use getBody if you used the BodyHandler in your route

[08:48:24] <myghty> pmlopes: well, but where is the difference?

[08:48:43] <myghty> I am in my route, getting a RoutingContext object, why should I use getBody instead of getBodyhandler

[08:49:35] <myghty> currently both deliver “null” even though I definitely send a body within my request to my verticle… dunno why that happens

[08:49:38] <pmlopes> the difference is that if you use the body handler it will make sure that the the request body is read and your handler is only invoked once the body is available, if you don't do this then you will to process it yourself

[08:50:01] <pmlopes> and to process it yourself you basically are reimplementing the body handler

[08:50:31] <pmlopes> see the example:

[08:51:10] <myghty> I see

[08:51:12] <pmlopes> Body handler will process multipart uploads and json uploads

[08:51:17] <myghty> ah no

[08:51:24] <myghty> I did not mean that one I think

[08:51:51] <pmlopes> but will also take care if the upload does not fall in these categories that you get a buffer in the context when you call getBody

[08:52:30] <myghty>

[08:52:58] <myghty> here I this HttpServer request, there I can set a body handler

[08:53:06] <myghty> is that the same you are referring to?

[08:53:49] <myghty> because I already have a handler handling the routing context

[08:54:04] <myghty> so in that handler I should just simply use context.getBody, right?

[08:55:08] <pmlopes> no that is not the same. See the example they are 2 different things

[08:55:37] <myghty> yes exactly, that was what I figured

[08:56:02] <pmlopes> in order to do it yourself, first you need to inform vertx that you expect uploads with: setExpectMultipart(true)

[08:56:13] <myghty> ah no, I am not expecting uploads or something

[08:56:59] <pmlopes> then you set a request.setBodyHandler to process the body (basically reimplementing something like:

[08:57:03] <myghty> I have a simple httpServer verticle, expecting json in the body

[08:57:32] <myghty> ah

[08:57:33] <myghty> damn…

[08:57:36] <myghty> that might be an issue

[08:57:38] <myghty> thanks!

[08:58:14] <myghty> I thought I can simply implement a normal Handler

[08:58:48] <pmlopes> you can but you will have to handle failures, DDoS, etc… and the vertx-web BodyHandler class does that for you

[09:00:22] <myghty> I see :)

[09:04:29] <myghty> will try that, thanks :)

[09:05:59] <myghty> hm strange

[09:06:11] <myghty> even though I now set the body handler for all incoming requests

[09:06:20] <myghty> the body arrives still empty

[09:30:13] <pmlopes> can you share your code? just the upload part?

[09:30:25] <pmlopes> it will be hard to help you out now without it

[10:25:53] <myghty> pmlopes: will try to build a small reproducer

[10:26:08] <myghty> sadly highly confidential so I must be careful with what I share if I do not want to get kicked out

[10:46:36] * ChanServ sets mode: +o temporal_ [11:07:43] <myghty> strange [11:07:58] <myghty> pmlopes: I can confirm, that with the bodyhandler attached it works on my windows maschine :) [11:08:01] <myghty> thanks for that hin [11:08:02] <myghty> hint [11:08:26] <myghty> but sadly my remote server where I am deploying the stuff is a damn old solaris maschine, and there context.getBody() always returns null [11:08:30] <myghty> totally awkward [11:08:54] <myghty> even with my simplest reproducer, just an http verticle, adding bodyhandler, calling routingContext.getBody() is null [12:40:50] <matzew> Hello [12:41:10] <matzew> when building the branch, I see some newly generated files, and modifications: [12:41:19] <matzew> is that expected ? Feels a bit odd … :D [13:51:08] <matzew> ppatiern, any thoughts ? [13:56:54] <pmlopes> @mighty I don't have a solaris machine, do you think a opensolaris 2009.06 is good enough? I haven't used it since… 2010~1011 :) [14:00:00] <ppatiern> matzew: sorry … today I'm working on a feature for the MQTT server :-) [14:00:08] <ppatiern> I'll jump to your PR asap [14:31:10] * ChanServ sets mode: +o temporalfox

[14:40:27] <matzew> ppatiern, no hurry - I just found the .adoc update and new generated file _weird_

[14:42:14] <ppatiern> matzew it's not strange I think the PR committer didn't compile the other language (kotlin) and/or forgot to commit them

[14:54:46] <AlexLehm_> matzew, ppatiern: i would usually expect that the PRs do not include the generated sources and the sources are regenerated after the pr is merged in the master branch

[14:55:07] <AlexLehm_> could cause less conflicts

[14:56:29] <matzew> AlexLehm, yeah, I agree

[14:56:48] <matzew> ppatiern, It's not really related to my code - at least i dont see the connection, tbh

[14:56:52] <ppatiern> AlexLehm_ yes you are right

[14:57:12] <ppatiern> matzew: it's not related to your code, same happens here locally without your code ;)

[14:57:23] <matzew> ah

[14:57:37] <matzew> I started to really wonder if I had a few pints too much last night :)

[14:58:05] <ppatiern> :)

[15:01:11] <AlexLehm_> if something was changed in a language generator in the meantime, the changes could be unreleated and however builds it next gets to commit the changes :-)

[15:01:21] <AlexLehm_> whoever

[16:17:02] <RebelGeek> Hi guys, first off I'd like to thank you for creating such an awesome piece of software!

[16:18:25] <RebelGeek> I'm using 3.4.0 within CloudFoundry using their SSO tile…

[16:18:54] <RebelGeek> I'm successful at getting authorized using the OAuth2 classes

[16:19:43] <RebelGeek> but upon return to the application via the callback, I'm getting “unauthorized: Bad Credentials”

[16:20:20] <RebelGeek> Not sure why

[16:20:33] <RebelGeek> What could caused that in an SSO environment?

[16:34:22] <pmlopes> @RebelGeek the callback can only be used once, if you refresh the page you'll not have the corrent challenge and will not be logged in again. You need to have a SessionHandler and CookieHandler to keep the state

[16:34:46] <RebelGeek> I have both

[16:35:04] <RebelGeek> I also have a UserSessionHandler

[16:35:21] <pmlopes>

[16:35:37] <pmlopes> these must be before the Oauth handler

[16:36:01] <RebelGeek> the OAuth handler is last

[16:37:39] <pmlopes> so when you say return via the callback, what do you mean with that? is that the oauth2 callback url in your vertx app?

[16:37:56] <RebelGeek> Yes

[16:38:11] <RebelGeek> I see it coming back with a token and a correct state

[16:39:13] <pmlopes> so that is the problem, the callback should be only called by cloudfoundry itself and when it does that it always comes with a new challenge so if you go there manually there is challenge or you're using a browser cached one and will be invaldated and logged out

[16:39:21] <RebelGeek> I was trying to find where the exception was occurring to see the condition. The exception is being thrown in the RoutingContextImplBase

[16:39:33] <pmlopes> if you're using cookies you should go to the protected resource not the callback

[16:40:27] <pmlopes> Could you make an simple reproducer so we can look up at the exception and see what is going on?

[16:41:56] <RebelGeek> Do you want to see how I coded it?

[16:42:21] <pmlopes> yes

[16:42:25] <RebelGeek> Ok

[16:43:02] <RebelGeek> Should I paste it here or email…?

[16:43:25] <pmlopes> the best is if you could make a

[16:43:54] <RebelGeek> Ok

[16:44:42] <RebelGeek> The only question I have is how are you going to test without being in my company's environment?

[16:46:09] <pmlopes> I can't :)

[16:47:32] <pmlopes> have you tried to see if after login, returning to the app not to the callback, that it works? if that works it is fine

[16:48:06] <pmlopes> brb

[16:48:17] <RebelGeek> Yes. It tries to re-authenticate.

[16:48:32] <RebelGeek> So it takes me back to the page where CF asks my permission

[16:52:06] <RebelGeek>

[16:57:27] <pmlopes2> if you move the redirect auth handler creation right before it's usage at the end it might solve your problem

[16:58:52] <pmlopes2> the issue is that at config when you setup the callback path, this route is added before the session handler is added so there is no session check performed

[17:06:46] <RebelGeek> ic

[17:06:57] <RebelGeek> Going to try now….

[17:38:45] <matzew> ppatiern, I see you fixed the issue, I've just rebased my PR ;-)

[17:39:22] <ppatiern> matzew: yes I'm taking a look to your PR. I'm closed to merge it ;)

[17:42:22] <matzew> :-)

[18:24:17] <RebelGeek> pmlopes that didn't seem to work. Same result.

[19:47:53] <pmlopes> @RebelGeek then we need a reproducer in order to test. It seems to be a very specific issue.

[22:45:40] <RebelGeek> @pmlopes It seems the error is occurring in the UserSessionHandler specifically in the addHeaderEndHandler. It seems the routingContext.user() is null