[09:29:32] <xkr47> millrossjez, thanks will check it out!
[09:29:48] <xkr47> cescoffier, like “Companies that use vert.x” ?
[09:30:02] <cescoffier> xkr47 : yes
[09:37:00] * ChanServ sets mode: +o purplefox_ [09:38:05] <xkr47> millrossjez, but generally we'd like to have as much things nonblocking as we can [09:38:53] <xkr47> millrossjez, but even if we end up not using the impl having the same or similar api is probably worth considering [10:17:27] <millrossjez> in which case I can see you may be submitting a few vert.x PRs ;) [10:18:09] <millrossjez> (that last was to @xkr47) [10:18:58] <millrossjez> as far as I know the only nonblocking authN stuff is that provided by the main vert.x project [11:37:53] * ChanServ sets mode: +o purplefox_
[14:06:36] * ChanServ sets mode: +o purplefox [15:54:48] <myghty> hi there [15:54:51] <myghty> just a short question… [15:55:02] <myghty> when does the response from HttpServer usually get written? [15:55:03] <myghty> oO [15:55:19] <myghty> Because I just set the status code, afterwards wanna set headers but it tells me “already written” [16:01:55] <myghty> aaaah… found it… [16:02:02] <myghty> I had a try catch around everythin… [16:02:09] <myghty> put there a “finally write” [16:02:16] <myghty> to make sure that it really writes my response… [17:27:56] <temporal_> hi ppatiern have you time to investigate the kafka-client failures ? [17:28:11] <temporal_> I would like to have the CI pass tests [17:30:36] <ppatiern> temporal_: I investigated last weekend with no good results … for what I see it seems that on CI after every tests the topic log isn't deleted and some messages are already there … the saved offset is already there and the consumer starts to read from there so it happens something like key-0 != key-5364 [17:30:51] <ppatiern> having that huge key means that from previous tests the topic is still full of messages [17:30:52] <temporal_> so it's a build issue ? [17:30:58] <ppatiern> it doesn't happen locally [17:31:02] <temporal_> yes it does not [17:31:20] <temporal_> should we have one directory for each unit test ? [17:31:25] <temporal_> in target [17:32:05] <ppatiern> it could be a good idea even if I not understand why on CI after every test, the kafka cluster directory isn't cleaned properly [17:32:11] <ppatiern> do we have a way to verify that on CI ? [17:32:27] <ppatiern> or we could try a different topic for each test [17:32:38] <ppatiern> it could be another option … to avoid overlap [17:38:20] <ppatiern> temporal_: btw I'll fix it because I need a compiled version in order to start using it in the AMQP-Kafka bridge [17:38:36] <temporal_> sure, but was just wondering about the cause [17:38:48] <temporal_> I'm trying to gather the bits for a 3.4.0 beta release in january [17:39:10] <temporal_> for mqtt server, I think the best is that I help you implementing server sharing [17:39:17] <temporal_> using the existing vertx class that does it [17:39:25] <ppatiern> for that beta I need to write few doc for mqtt server as well [17:39:26] <temporal_> I've used it in my gRPC prototype [17:39:35] <temporal_> we need doc yes indeed to bei n the stack [17:39:59] <temporal_> https://github.com/vietj/vertx-grpc/commit/4813ae14c977761ea3d57d3ee93bffa13cc9f14d [17:40:10] <temporal_> see the usage of io.vertx.core.net.impl.HandlerManager [17:40:14] <ppatiern> regarding the server sharing there is no rush for now … both for Hono and EnMasse [17:40:16] <temporal_> that's what we should use in mqtt server [17:40:23] <ppatiern> ok thanks ;= [17:40:24] <ppatiern> ;) [17:40:35] <temporal_> yes but htat can help me make it more easy to reuse [17:40:38] <temporal_> and perhaps rework some part of VertxInternal [17:40:53] <temporal_> to allow it more easily [17:41:12] <temporal_> for now I think we don't have the bandwidth to make the NetServer extensible [17:41:24] <temporal_> so I would stick to the current situation taht is not that bad [17:41:32] <ppatiern> ok [17:41:35] <temporal_> I whish I can make some parts of vertx reusable [17:41:38] <temporal_> like the SSLHElper [17:41:42] <temporal_> and this handler manager [17:42:30] <ppatiern> SSL is another stuff we need .. yes [17:42:35] <temporal_> it's easy [17:42:36] <temporal_> [19:56:36] * ChanServ sets mode: +o purplefox
[20:14:28] <Sticky> eurgh, ssl in java in general seems way more complex that it should be
[21:12:10] * ChanServ sets mode: +o purplefox [21:47:05] * ChanServ sets mode: +o temporalfox
[22:10:06] <temporalfox> Sticky once you have a good facade for SSL, it's easy