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

[00:22:42] <temporalfox> ChicagoJohn you an use getNow

[00:22:47] <temporalfox> you can use getNow

[00:23:08] <temporalfox> and it kicks off automatically if you start to write buffers in the requests

[00:23:13] <temporalfox> but you still need to end it

[00:23:24] <temporalfox> specially for chunked content

[00:23:26] <temporalfox> encoding

[09:40:27] <gokl> Hi, I have a more general event driven question, but maybe you have an idea. I have a timer task that restarts itself in the end via vertx.setTimer(timeToWait, this);. Now it happened to me that during some io operations in the task exceptions occured and no event handler under my controll have been called. So my task got stuck. It died. Could not restart itself. Is there any name for this problem? Is there a pattern to avoid this?

[09:49:05] <pouyanster> @gokl this might help you

[09:56:13] <gokl> pouyanster: The thing is that the verticle is not dead. It is waiting for a handler to be called. This handler will be called after some io events. There was a NPE in code I don't controll. ContextImpl.wrapTask cought the exception, but my handler will never be called. Thus my task is effectively dead, waiting forever for a handler to be called.

[09:56:50] <gokl> I would like to have a way to handle this proactively.

[10:03:54] <pouyanster> gokl: So you have a verticle, which implements a handler, which is never called?

[10:05:23] <pouyanster> (due to an NPE)

[10:05:42] <gokl> Yes

[10:06:48] <pouyanster> not even after 30 sec?

[10:06:53] <gokl> Well, i have a worker verticle, which runs a setTimer task, which has a handler, which is never called.

[10:07:05] <gokl> Not even after hours :-)

[10:07:27] <pouyanster> so you are not waiting for a reply?

[10:07:44] <pouyanster> but rather your handler is registered on a specific address?

[10:09:02] <pouyanster> Sorry, I might not be of help here. I know for reply handlers you can set a timeout handler, which is invoked when no reply is received

[10:09:29] <cescoffi_> pouyanster gokl : Sorry taking the conversation in the middle. If I get it right, you have a handler not called. Is it a request-reply on the eventbus ?

[10:09:50] <cescoffi_> pouyanster gokl : in that case you can configure a timeout, and you will get a failure is the timeout is reached

[10:09:56] <gokl> In my special case I'm doing a http request via vertx HttpClient. The connect failed. See the exception . So all handlers from the HttpClient, be exception and others, are not

[10:10:10] <pouyanster> @cescoffi_ I think he has another problem, which cannot be solved with DeliveryOptions

[10:10:17] <pouyanster> or she

[10:10:34] <pouyanster> [unknown:circ][unknown:circ]

[10:11:00] <cescoffi_> gokl pouyanster : that rather sounds like a bug in vert.x

[10:11:26] <cescoffi_> gokl pouyanster : if it's a HTTP client, register the 2 exceptionHandlers and check whether or not you get a failure

[10:11:27] <gokl> I could fix that with a timeout. Sure. But that way I cannot be certain that the handler crashed or is just slow. I would like to have a solution which is 100% certain..

[10:11:38] <pouyanster> gokl: I think it would help if you pastebin some snippet

[10:11:41] <gokl> The exception handlers are not beeing called

[10:11:56] <gokl> I cannot reproduce it. It was on our live servers.

[10:12:03] <gokl> remoteAddress was null

[10:12:48] <pouyanster> thats a good point, you're making :-/

[10:12:56] <temporalfox> which version is it ?

[10:13:19] <gokl> 3.2.1

[10:13:28] <temporalfox> can you try with 3.3.0.CR2 ?

[10:13:56] <gokl> I followed the code and it seems remoteAddress can be null. But I could't figure out how to reproduce it.

[10:14:13] <temporalfox> you just had it once ?

[10:14:48] <gokl> Several times in the same time. Probably due to some network issues. It does not happen anymore now.

[10:15:06] <temporalfox> can you open an issue in dropwizard project ?

[10:15:22] <gokl> But that led to to the idea to somehow detect a handler will not be called anymore because it crashed.

[10:15:37] <gokl> Yes, I will open an issue

[10:27:34] <cescoffi_> thanks gokl (

[19:24:03] <namrood> Here does anyone know why my vertx build is failing I'm on mac and I can't build vert.x repo

[19:27:34] <Sticky> well we would probably need more info

[19:28:57] <namrood> A few test cases are failing

[19:29:05] <namrood> Usually related to OpenSSL

[19:29:17] <namrood> SEVERE: Unhandled exception

[19:29:17] <namrood> io.vertx.core.VertxException: io.vertx.core.VertxException: OpenSSL server key/certificate must be configured with .pem format

[19:29:18] <namrood> at

[19:29:18] <namrood> at

[19:29:18] <namrood> at

[19:29:19] <namrood> at io.vertx.core.http.impl.HttpServerImpl.listen(

[19:29:21] <namrood> at io.vertx.core.http.impl.HttpServerImpl.listen(

[19:29:23] <namrood> at io.vertx.test.core.HttpTestBase.lambda$startServer$3(

[19:29:25] <namrood> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(

[19:29:27] <namrood> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(

[19:29:29] <namrood> at

[19:29:31] <namrood> at io.netty.util.concurrent.SingleThreadEventExecutor$

[19:29:33] <namrood> at

[19:29:35] <namrood> Caused by: io.vertx.core.VertxException: OpenSSL server key/certificate must be configured with .pem format

[19:29:39] <namrood> at

[19:29:41] <namrood> … 10 more

[19:29:43] <namrood> java.lang.AssertionError

[19:29:45] <namrood> at

[19:29:47] <namrood> at org.junit.Assert.assertTrue(

[19:29:49] <namrood> at org.junit.Assert.assertTrue(

[19:29:51] <namrood> at io.vertx.test.core.AsyncTestBase.assertTrue(

[19:29:53] <namrood> at io.vertx.test.core.AsyncTestBase.awaitLatch(

[19:29:55] <namrood> at io.vertx.test.core.HttpTestBase.startServer(

[19:29:57] <Sticky> use gist/pastebin

[19:29:57] <namrood> at io.vertx.test.core.Http2ServerTest.testConnectionHandler(

[19:29:59] <namrood> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[19:30:01] <namrood> at sun.reflect.NativeMethodAccessorImpl.invoke(

[19:30:03] <namrood> at sun.reflect.DelegatingMethodAccessorImpl.invoke(

[19:30:05] <namrood> at java.lang.reflect.Method.invoke(

[19:30:09] <namrood> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(

[19:30:11] <namrood> at

[19:30:13] <namrood> at org.junit.runners.model.FrameworkMethod.invokeExplosively(

[19:30:15] <namrood> at org.junit.internal.runners.statements.InvokeMethod.evaluate(

[19:30:17] <namrood> at org.junit.internal.runners.statements.RunBefores.evaluate(

[19:30:19] <namrood> at org.junit.internal.runners.statements.RunAfters.evaluate(

[19:30:21] <namrood> at org.junit.rules.TestWatcher$1.evaluate(

[19:30:23] <namrood> at org.junit.rules.RunRules.evaluate(

[19:30:25] <namrood> at org.junit.runners.ParentRunner.runLeaf(

[19:30:27] <namrood> at org.junit.runners.BlockJUnit4ClassRunner.runChild(

[19:30:29] <namrood> at org.junit.runners.BlockJUnit4ClassRunner.runChild(

[19:30:31] <namrood> at org.junit.runners.ParentRunner$

[19:30:33] <namrood> at org.junit.runners.ParentRunner$1.schedule(

[19:30:35] <namrood> at org.junit.runners.ParentRunner.runChildren(

[19:30:39] <namrood> at org.junit.runners.ParentRunner.access$000(

[19:30:41] <namrood> at org.junit.runners.ParentRunner$2.evaluate(

[19:30:43] <namrood> at

[19:30:45] <namrood> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(

[19:30:47] <namrood> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(

[19:30:49] <namrood> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(

[19:30:51] <namrood> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(

[19:30:53] <namrood> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(

[19:30:55] <namrood> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(

[19:30:57] <namrood> at org.apache.maven.surefire.booter.ForkedBooter.main(

[19:30:59] <namrood>

[19:33:17] <Sticky> what test?

[19:34:36] <namrood> i'm running the whole suite

[19:34:40] <namrood> mvn test

[19:34:58] <namrood> i wonder if there's any configuration to be done on my mac

[19:35:39] <Sticky> well it seems that whatever pem file is used in the test is bing rejected as valid

[19:36:14] <Sticky> there are however lots of test pem files, so its hard to say which one it is

[19:37:27] <Sticky> actually may not be invalid pem file, may be a lack of pem file entierly

[19:37:27] <namrood> Am I the only one running into those issues?

[19:50:02] <temporalfox> namrood I think you don't have the alpn agent

[19:50:06] <temporalfox> that is the correct version

[19:50:14] <temporalfox> what is your JDK version ?

[19:50:35] <temporalfox> are you using ALPN ?

[19:51:40] <namrood> I'm using idk 1.8.0_92

[19:51:58] <temporalfox> ok

[19:52:01] <temporalfox> are you using ALPN ?

[19:52:11] <namrood> no

[19:52:19] <namrood> googling how to set it up now

[19:52:23] <temporalfox> no

[19:52:25] <temporalfox> you shouldnt

[19:52:28] <temporalfox> what is your version ?

[19:52:37] <temporalfox> are you using 3.3.0-SNAPSHOT ?

[19:52:40] <namrood> yes

[19:53:03] <Sticky> I just did a full build, I had test failures but nothing ssl related

[19:53:06] <temporalfox> can you post your code somewhere ?

[19:53:12] <temporalfox> Sticky what errors ?

[19:53:21] <namrood> hang on kicking off a new build

[19:53:30] <temporalfox> ok

[19:53:40] <temporalfox> normally if you don't use ALPN it should use JDK SSL

[19:53:47] <temporalfox> unless you configured to use OpenSSL yourself

[19:54:08] <Sticky> temporalfox:

[19:54:22] <temporalfox> Sticky cool

[19:54:27] <temporalfox> we do have the same failures in CI

[19:54:31] <temporalfox> I think

[19:54:38] <temporalfox> and they don't reproduce for us locally

[19:55:00] <temporalfox>

[19:55:06] <temporalfox> does it always happen ?

[19:55:13] * Sticky retests

[19:56:45] <Sticky> `mvn clean test -Dtest=BareCommandTest` just passed 4 times in a row

[19:56:54] <namrood> @temporalfox I have the default OpenSSL implementation locally

[19:56:58] <namrood> still seeing the same error

[19:57:04] <namrood>

[19:57:09] <temporalfox> if you are using openssl it's normal

[19:57:13] <temporalfox> you need to use .pem format

[19:57:18] <temporalfox> other are not supported

[19:57:37] <temporalfox> how are you configuring your SSL ?

[19:57:41] <namrood> Do you know any workaround to disable it?

[19:57:44] <temporalfox> can you show me the code ?

[19:57:51] <namrood> I haven't written any code I am just running a vert.x build

[19:57:56] <temporalfox> ah ok

[19:58:04] <temporalfox> vertx core build ?

[19:58:07] <temporalfox> which build ?

[19:58:28] <namrood> from master

[19:58:39] <temporalfox> ok

[19:58:45] <temporalfox> so both of you are building master

[19:58:51] <temporalfox> and both of you have different failures

[19:59:07] <namrood> I removed openssl and kicking off a new build now

[19:59:23] <temporalfox> do you have in your POM

[19:59:23] <temporalfox> <jetty.alpnAgent.version>2.0.3</jetty.alpnAgent.version>

[19:59:25] <temporalfox> ?

[19:59:38] <temporalfox> because it should be this version that is compatible with latest Oracle JDK

[19:59:46] <namrood> checking

[19:59:53] <temporalfox> we had similar issue a few days ago

[20:00:13] <temporalfox> so basically you are running alpn tests with open ssl

[20:00:53] <temporalfox> perhaps that for the non OpenSSL TLS tests we should force to use JDK SSL engine explicitely instead of auto use

[20:00:57] <namrood> alpn version was 2.0.2

[20:01:28] <namrood> temporal fox I also have a PR for the vertx-parent, i will be pushing the code shortly

[20:02:39] <temporalfox> vertx-parent ?

[20:02:46] <temporalfox> we don't plan to release a new vertx parent soon

[20:02:53] <temporalfox> what is it about ?

[20:03:05] <temporalfox> using 2.0.3 will solve the problem

[20:13:13] <Sticky> temporalfox: `mvn clean test -Dtest=SLF4JLogDelegateTest,BareCommandTest` reliably fails, provided SLF4JLogDelegateTest is first in the build, BareCommandTest will fail

[20:13:23] <temporalfox> interesting

[20:13:28] <temporalfox> so it's a file system issue

[20:13:37] <temporalfox> i.e “ls” is not the same on Mac than on cloudbees

[20:13:41] <temporalfox> let me try

[20:13:41] <Sticky> SLF4JLogDelegateTest may mess with statics

[20:13:54] <temporalfox> yeah…

[20:13:55] <Sticky> since I assume you resue the jvm between tests

[20:14:01] <temporalfox> perhaps I will run them as integration tests

[20:14:08] <temporalfox> ah it passes for me :-)

[20:14:23] <temporalfox> but it executes first

[20:14:26] <namrood> temporalfox my update has some plugins updates

[20:14:27] <temporalfox> BareCommandTests

[20:14:38] <temporalfox> namrood we are not going to update plugin for 3.3.0

[20:14:39] <namrood> mostly for the compiler plugin

[20:14:41] <namrood> ok

[20:14:53] <temporalfox> Sticky

[20:14:57] <namrood> has been fixed by the way and released in the 3.5.1

[20:14:58] <Sticky> yes

[20:15:12] <temporalfox> I think what are you saying makes sense

[20:15:26] <temporalfox> but on my machine I can verify it is true

[20:15:46] <Sticky> cant?

[20:15:53] <temporalfox> can't

[20:15:57] <temporalfox> namrood never experienced this issue

[20:16:30] <temporalfox> I think we should move then SLF4J tests as integration tests in their own VM maybe

[20:16:35] <namrood> +1

[20:17:53] <temporalfox> I will give a try

[20:18:21] <Sticky> I can probably debug it and find the issue

[20:19:51] <temporalfox> it would be good too

[20:21:23] <temporalfox> @BeforeClass

[20:21:23] <temporalfox> public static void initialize() throws IOException {

[20:21:23] <temporalfox> System.setProperty(“vertx.logger-delegate-factory-class-name”, SLF4JLogDelegateFactory.class.getName());

[20:21:23] <temporalfox> LoggerFactory.initialise();

[20:21:25] <temporalfox> }

[20:21:36] <temporalfox> this could be set by the integration tests instead of being here

[20:21:39] <temporalfox> would make more sense

[20:21:43] <temporalfox> but well

[20:21:53] <temporalfox> then it would not run in IDE out of the box anymore

[20:21:57] <temporalfox> so gonna let it there

[20:23:40] <temporalfox> I'm pushing this

[20:23:46] <temporalfox> let's see how cloudbees reacts

[20:45:15] <Sticky> it does not help for me

[20:46:06] <Sticky> I believe the problem is that the HAManager class has already been loaded by the classloader, so had its static logger set

[20:46:35] <Sticky> so when you try to redirect the error stream it does not effect the logger that has already been set in the HAManager class

[21:01:03] <temporalfox> hi AlexLehm

[21:14:56] <Sticky> yeah you are a bit screwed on this, think your only options are A) Run BearCommandTest in a new JVM, i.e I assume what you are proposing with integration tests B) Implement a test wide method to access lines that are logged to slf4j

[21:16:15] <Sticky> or C) Fix tests to not use logging to assert the state of the system, to some extent this is the real way to do it right

[21:42:43] <joem86> I'm setting up long-polling for SQS in a worker verticle. I think I need to have my listener loop in the start() method, but that would mean that the start() method never returns until stop() is called. Does that sound right?

[21:43:30] <temporalfox> joem86 you should do polling using a Timer

[21:43:58] <temporalfox> perhaps using runOnContext

[21:44:03] <temporalfox> that would be interesting to examile

[21:44:05] <temporalfox> examine

[21:44:23] <temporalfox> so in start method you do runOnContext on Context

[21:44:47] <temporalfox> actually I think it would be the smae problem because it could block indefinitely

[21:45:02] <temporalfox> so joem86 I think you don't have to use a worker verticle

[21:45:18] <temporalfox> worker verticle is for executing blocking tasks that will complete

[21:45:38] <temporalfox> upon an external stimuli (i.e an event bus message for instance)

[21:45:47] <temporalfox> instead I would rather do a classic Verticle

[21:46:05] <temporalfox> and in start() : start a plain Java Thread

[21:46:12] <temporalfox> when you poll a message from this thread

[21:46:23] <temporalfox> you dispatch it somewhere (event bus ?)

[21:50:40] <joem86> sure, that would work. A java thread in a standard verticle is not considered an “advanced feature” like multi-threaded worker verticles, right?

[21:53:53] <joem86> as a basic example, in start() I could have new Thread1) {

[21:57:43] <temporalfox> }

[21:57:53] <temporalfox> and in stop : thread.interrupt()

[21:58:03] <temporalfox> that allows to handle thread interruption at the same time

[21:58:14] <joem86> nice tip, thanks!

[21:58:16] <temporalfox> but well - in short it would work for what you want to do

[21:58:37] <temporalfox> what are you doing with polled messages ? you hand them off on the event bus ?

[21:59:04] <joem86> exactly. This verticle only has the responsibility to hand a received SQS message off to the event bus

[21:59:33] <joem86> That way we can plug in another messaging service in the future just by writing another “receiver” verticle

[22:00:45] <joem86> actually since standard verticles are guaranteed to be called on the same event loop I shouldn't need volatile since it's on the same thread

[22:00:49] <joem86> d'oh!

[22:01:01] <joem86> nvm it's checked inside my java thread

[22:08:43] <temporalfox> :-)

[22:26:01] <AlexLehm> temporalfox: Hi Julien

[22:26:12] <temporalfox> AlexLehm hi

[22:26:20] <AlexLehm> will take a look at the dns code now

[22:26:23] <temporalfox> I see fialures in vertx mail on Cloudbees

[22:26:45] <temporalfox>

[22:26:53] <temporalfox> yes

[22:26:53] <temporalfox> that too :-)

[22:27:21] <AlexLehm> the mail project fails because it does something wrong with the resolution of LOCALHOST

[22:28:14] <AlexLehm> I assume ec2.local is the default domain of the jenkins host and that gets appended as domain for some reason

[22:28:56] <AlexLehm> or it in the search domains maybe

[22:29:08] <amr> are you guys familiar with any netty and vertx2 issues?

[22:29:13] <amr> like, versions not agreeing?

[22:29:53] <temporalfox> in which part AlexLehm ?

[22:29:58] <temporalfox> can you point out some code ?

[22:30:12] <temporalfox> amr not really but we can still try to help

[22:32:48] <AlexLehm> the unit test is this one:

[22:33:09] <AlexLehm> but the issue is probably in the hostname resolution, not in the tls code or so

[22:33:44] <temporalfox> yep

[22:33:58] <temporalfox> it does not fail for me locally

[22:34:07] <AlexLehm> let me check if that fails on windows as well

[22:36:02] <temporalfox> ok

[22:36:04] <temporalfox> so I think that

[22:36:17] <temporalfox> the OS provides a search domain “ec2.local”

[22:36:44] <temporalfox> and that LOCALHOST.ec2.local is attempted to be resolved

[22:36:47] <temporalfox> not sure though :-)

[22:37:09] <temporalfox> will try to push some code to see how it reacts

[22:38:01] <temporalfox> I will try to run the test with a search domain

[22:38:05] <temporalfox> ec2.local

[22:38:07] <temporalfox> to see

[22:38:49] <AlexLehm> ok, in windows the test works, but it doesn't resolv.conf i think

[22:39:05] <temporalfox> no its not that

[22:39:24] <temporalfox> the resolver does not use resolv.conf

[22:39:29] <temporalfox> it uses the Sun api

[22:39:32] <temporalfox> that does native calls

[22:39:36] <temporalfox> I mean JNI

[22:39:42] <temporalfox> that goes in windows registry

[22:40:23] <temporalfox> actually seems to be

[22:40:23] <temporalfox> ec2.internal

[22:44:28] <temporalfox> actually I'm not using latest 3.3 snapshots

[22:44:37] <temporalfox> (not installed)

[22:44:54] <temporalfox> AlexLehm on windows how are you setting up the search domain ?

[22:45:07] <temporalfox> got the failure on my machine

[22:45:24] <temporalfox> why are you using LOCALHOST ?

[22:45:29] <temporalfox> instead of “localhost”

[22:45:34] <temporalfox> I think it's because of that

[22:46:01] <temporalfox> it's not picked up by the /etc/hosts resolver

[22:46:10] <temporalfox> and then it uses Cloudbees search domains

[22:46:23] <temporalfox> and it does not find it

[22:46:26] <AlexLehm> initially I meant to test the cert checking of the ssl connect and I have a cert with localhost and the connection uses LOCALHOST or localhost to check if the cert matches

[22:46:53] <AlexLehm> does the cloudbees vm contain an entry for localhost?

[22:47:13] <temporalfox> I think it does

[22:47:16] <temporalfox> I don't know

[22:47:25] <temporalfox> pehraps on CB it was resolved via DNS

[22:47:35] <temporalfox> and so it messes up with search domains

[22:47:37] <temporalfox> ?

[22:47:41] <temporalfox> it doees the query

[22:47:46] <temporalfox> LOCALHOST.ec2.internal

[22:48:35] <temporalfox> I think it's vertx issue

[22:48:35] <AlexLehm> ok, so the fix for the case-insitive hosts file resolution is not working?

[22:48:47] <temporalfox> because the LOCALHOST check

[22:48:53] <temporalfox> is done via hosts

[22:48:55] <temporalfox> and it does not find it

[22:49:01] <temporalfox> it's done in netty

[22:49:05] <temporalfox> not in vertx I think

[22:49:10] <temporalfox> where is it in Netty ?

[22:49:14] <AlexLehm> I had previously contributed the fix for the LOCALHOST error to netty and that was merged by Norman

[22:49:35] <temporalfox> yes in vertx it's a plain hashmap lookup

[22:49:48] <temporalfox> try {

[22:49:49] <temporalfox> if (!entries.containsKey(“localhost”)) {

[22:49:49] <temporalfox> entries.put(“localhost”, InetAddress.getByName(“localhost”));

[22:49:51] <temporalfox> }

[22:49:51] <temporalfox> } catch (UnknownHostException ignore) {

[22:49:53] <temporalfox> }

[22:49:53] <temporalfox> builder.hostsFileEntriesResolver(entries::get);

[22:49:58] <temporalfox> so it's not case sensitive

[22:50:06] <temporalfox> can you show me the netty fix ?

[22:50:51] <AlexLehm> yes, i just have to find my part

[22:51:36] <AlexLehm> netty/resolver/src/main/java/io/netty/resolver/

[22:52:04] <AlexLehm> and

[22:52:34] <temporalfox> in which version is it fixed ?

[22:52:42] <temporalfox> 4.1.1.Final or after ?

[22:52:44] <AlexLehm> ah, if the hashmap contains lowercase entry for localhost, the lookup has to be get(key.toLowerCase())

[22:52:54] <AlexLehm> i think 4.1.1.Final

[22:53:17] <AlexLehm> I activated the test in vertx-mail when we changed the netty version of 4.1.1.Final I think

[22:53:37] <temporalfox> ok so we need something similar

[22:54:18] <temporalfox> we're using

[22:54:22] <temporalfox> builder.hostsFileEntriesResolver(entries::get);

[22:54:32] <temporalfox> and we should properly build a DefaultHostsFileEntriesResolver instead

[22:54:53] <temporalfox> prb is hardcoded

[22:54:53] <temporalfox> private final Map<String, InetAddress> entries = HostsFileParser.parseSilently();

[22:54:55] <temporalfox> that's why I haven't used it

[22:55:02] <temporalfox> it should be able to accept any Map as well

[22:55:05] <temporalfox> so it can be reuse

[22:55:06] <temporalfox> d

[22:55:58] <temporalfox> builder.hostsFileEntriesResolver(inetHost → entries.get(inetHost.toLowerCase(Locale.ENGLISH)));

[22:56:05] <temporalfox> at the same time it can be just a lambda :-)

[22:56:20] <AlexLehm> yes that is correct I think

[22:56:53] <temporalfox> I think I ahven't used the DefaultHostsFileEntriesResolver because it was not flexible enough

[22:57:24] <temporalfox> probably it did not fail before because we were not implementing search domains in vertx dns ersolver

[22:57:27] <temporalfox> now test pass

[22:57:43] <AlexLehm> before it was using the netty code dirctly I think

[22:57:58] <AlexLehm> ok, good

[22:58:28] <temporalfox> going to push that

[22:58:51] <AlexLehm> ok, i ran the test on a linux vm and it fails with the same problem

[22:59:03] <AlexLehm> that is the default search domain because of my cable modem

[22:59:16] <AlexLehm> that should work when i fetch the new version

[23:01:06] <temporalfox> yes

[23:05:27] <temporalfox> AlexLehm

[23:05:32] <temporalfox> if we do

[23:05:34] <temporalfox> builder.hostsFileEntriesResolver(inetHost → {

[23:05:34] <temporalfox> InetAddress addr = entries.get(inetHost);

[23:05:35] <temporalfox> if (addr == null) {

[23:05:35] <temporalfox> addr = entries.get(inetHost.toLowerCase(Locale.ENGLISH));

[23:05:37] <temporalfox> }

[23:05:37] <temporalfox> return addr;

[23:05:39] <temporalfox> });

[23:05:46] <temporalfox> it is ok, right ?

[23:05:53] <AlexLehm> yes, that would work

[23:06:08] <AlexLehm> i assume you want to avoid the String operation?

[23:10:32] <temporalfox> yes

[23:10:47] <temporalfox> it's more creating a new string when it's not really necessary

[23:11:10] <temporalfox> actually I think we do have case insensitive hashmap in vertx

[23:11:14] <temporalfox> for headers

[23:11:39] <temporalfox> well it's good like this

[23:12:14] <AlexLehm> yes

[23:14:23] <temporalfox> CI is kickin in

[23:19:58] <AlexLehm> ok that worked

[23:20:59] <temporalfox> yep

[23:21:02] <temporalfox> thanks

[23:27:11] <AlexLehm> ok, getting back to the windows test now

[23:33:10] * ChanServ sets mode: +o temporal_ [23:35:50] <Guest26376> Hey. I'm trying out Vert.x (with websockets) for the first time and have some questions. I'd like to create a function that is dedicated to sending messages. Is there any way I can send a message from a client outside of the main connectWebSocket() context? [23:36:00] <Guest26376> Code I use as reference: [23:42:20] <temporal_> Guest26376 hi [23:43:18] <temporal_> can you give an example of what you want to achieve ? because there are several ways [23:43:34] <temporal_> I mean how you want to send / publish a message [23:44:39] <Guest26376> @temporal I have a application that has a certain state, when this state changes I want to send the new state to the connected websocket server [23:44:46] <Guest26376> @tempral_ [23:45:20] <temporal_> what does trigger the state change ? [23:45:29] <temporal_> i.e which thread is it ? [23:45:34] <temporal_> I believe that one way to do would be [23:45:42] <temporal_> that once the client is connected [23:46:03] <temporal_> set the Websocket [23:46:08] <temporal_> as a field of the Verticle [23:46:25] <temporal_> and have your verticle at the same time register an event bus handler [23:46:34] <temporal_> so it can receive messages about state changes of your application [23:46:39] <temporal_> when it receives a mssage [23:46:44] <temporal_> it uses the websocket [23:46:54] <temporal_> and btw your example is a Vert.x 2 example [23:47:20] <temporal_> Vert.x 3 examples are here [23:47:20] <temporal_> [23:49:13] * ChanServ sets mode: +o temporalfox

[23:49:28] <Guest26376> Is it possible to instantiate the websocket? Looks like the websocket() function just returns HttpClient

[23:49:52] <temporalfox> vertx.createHttpClient().setHost(“localhost”).setPort(8080).connectWebsocket(“/myapp”, new Handler<WebSocket>() {

[23:49:55] <temporalfox> you should do inside

[23:50:02] <temporalfox> this.websocket = websocket;

[23:50:03] <temporalfox> }

[23:50:49] <Guest26376> ah that's smart, didn't think of it that way, I will try it out

[23:51:04] <temporalfox> have you looked at eventbus consumer example ?

[23:51:11] <temporalfox> you would mix this with that

[23:53:16] <AlexLehm> I'm getting 4 test failures in the HostnameResolutionTest on Windows

[23:53:17] <Guest26376> I'm looking at it right now, it looks quite convenient

[23:54:38] <temporalfox> which tests ?

[23:56:55] <temporalfox> AlexLehm

[23:57:18] <AlexLehm> HostnameResolutionTest.testMultipleSearchDomain:572→AsyncTestBase.awaitLatch:592→AsyncTestBase.assertTrue:372 null

[23:57:19] <AlexLehm> HostnameResolutionTest.testNetSearchDomain:649→testNet:123→AsyncTestBase.awaitLatch:592→AsyncTestBase.assertTrue:372 null

[23:57:19] <AlexLehm> HostnameResolutionTest.testSearchDomain:495→AsyncTestBase.awaitLatch:592→AsyncTestBase.assertTrue:372 null

[23:57:19] <AlexLehm> HostnameResolutionTest.testSearchDomainWithNdots2:624→AsyncTestBase.awaitLatch:592→AsyncTestBase.assertTrue:372 null

[23:57:55] <temporalfox> can you put the failures in a gist ?

[23:58:08] <temporalfox> so it's easier to see where it fails :-)

[23:59:08] <Guest26376> @temporalfox it's working, thank you! Vert.x keeps looking more and more awesome :)

[23:59:22] <temporalfox> Guest26376 happy to read that

) → { while(listening) { … } }).start(); and in stop() I could have listening = false; [21:57:18] <temporalfox> joem86 yes - don't forget to set listening to volatile [21:57:24] <temporalfox> also if you want to do better [21:57:31] <temporalfox> you should handle the Thread interrutped case [21:57:34] <temporalfox> so something rather like [21:57:42] <temporalfox> while (!Thread.interrupted(