Differences

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

Link to this comparison view

irc:1481583600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[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 :-)