Differences

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

@@ Line 1: / Line 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_