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

[09:41:18] <matrium> Hi, I have some trouble with my vert.x ↔ elastic search integration test. both test frameworks require a “RunWith” with a specific class. since the elastic search test framework won't run at all without the runner, I thought I could just create a vert.x instance by hand in my @Before-Method. But when I'm trying to register my HTTP-Verticle, I'm getting a:

[09:41:23] <matrium> “java.lang.IllegalStateException: executor not accepting a task at io.netty.resolver.AddressResolverGroup.getResolver(AddressResolverGroup.java:58) at io.vertx.core.impl.AddressResolver.resolveHostname(AddressResolver.java:162) at io.vertx.core.impl.VertxImpl.resolveAddress(VertxImpl.java:683)”

[09:46:13] <tsegismont> not easy to say without the full stack trace, but it seems the executor is stopped, meaning Vert.x has been closed

[09:46:25] <matrium> traces back to my call to the “listen”-method of the http server

[09:50:36] <tsegismont> You should send an email to the user forum, with code snippets. Seems not an easy question to answer on IRC

[09:54:23] <matrium> ok, it seems that it can be traced back to subsequent vert.x initializations (after i've called vertx.close for the first time). I think the problem is, that I don't have a “TestContext” I can pass to the verticle initialization and the shutdown

[10:19:04] <matrium> ok, manually adding some semaphores fixed the issue

[10:19:40] <matrium> The vertex test runner blocks until everything is initialized/shut down before calling the test suites

[10:20:08] <matrium> Semaphore sem = new Semaphore(0); vertx.close(m → sem.release()); sem.acquire();

[14:08:23] <laudatio> hi

[14:08:38] <laudatio> i have a question for vertx

[14:09:21] <laudatio> lets say there is a verticle which sends a file

[14:09:58] <laudatio> and a verticle which consumes the file and send a reply

[14:10:03] <laudatio> to the sender

[14:10:42] <laudatio> now my compagnon have stopped and restarted the consumer verticle with kill-command on bash-shell

[14:10:58] <laudatio> and deleted the -vertx-folder

[14:11:37] <laudatio> i meant the .vertx-folder

[14:12:35] <laudatio> now there are coming periodically timeouts for the reply

[14:12:53] <laudatio> what is the meaning of that

[14:12:56] <laudatio> ?

[14:13:44] <laudatio> is vertx somehow awaiting an verticle with an old id which is not there and therefore the reply is timeouting for the sender?

[14:14:26] <laudatio> im using vertx 3.3.2

[14:33:32] <mweb84> hi there. I want to compress the body of PUT requests in vertx before storing them to redis. Is this supported by vert.x 3x?

[14:34:07] <mweb84> I want to compress the request body using gzip

[15:59:42] <temporalfox> mweb84 I don't think it is supported pmlopes can confirm or not

[16:00:00] <temporalfox> mweb84 is it a native feature of redis ?

[16:01:47] <pmlopes> @mweb84 redis does not do any kind of compression

[16:03:52] <pmlopes> you will need to compress the data yourself

[16:04:41] <mweb84> yes I dont want the data to be compressed by redis

[16:05:12] <mweb84> I want to take the body from the request, gzip it and then write the gzipped resource to redis

[16:05:52] <pmlopes> then you will need to do exactly that :) there is no helpers at the moment do do any of those tasks

[16:06:49] <mweb84> ok. the netty functionality cannot help me here?

[16:57:04] <hazelcastmemeber> Hi i have a problem

[16:57:24] <hazelcastmemeber> hazelcast making me crazy

[21:00:38] *** ChanServ sets mode: +o temporal_