Vertx load a huge javascript file - Thread blocked - vert.x

Question

at this time, i created an example github project - https://github.com/marcelalburg/vertx-hugejson-thread-block-example.
My problem is, that vertx blocks my thread during a js file deployment.
The server.js file in src/main/resources is aprox 4mb big - this should simulate my react redux server side rendering file (this one is aprox 1.2 mb pure javascript).
during the deployment, the nashorn engine try to load the file and during the parsing, vertx is blocked.
does anybody has an idea, how i can prevent this blocking ?
Thanks Marcel

Answer 1

Is that really a problem? I do also have similar Thread blocked logs in my project, where Jersey (I'm using https://github.com/englishtown/vertx-jersey) takes pretty long time to start up.
To quote the documentation:
If you do that, then that event loop will not be able to do anything else while it’s blocked. If you block all of the event loops in Vertx instance then your application will grind to a complete halt!
You don't need (and probably want) to process other, including client, requests, so for me it's completely OK to block event loop at this stage.

Answer 2

I'm not sure I understand your question, but it's loading QUITE fast for me:
gorre#doom $ java -jar target/application.jar
May 11, 2016 10:39:47 AM com.hazelcast.instance.DefaultAddressPicker
INFO: [LOCAL] [dev] [3.5.2] Prefer IPv4 stack is true.
May 11, 2016 10:39:47 AM com.hazelcast.instance.DefaultAddressPicker
INFO: [LOCAL] [dev] [3.5.2] Picked Address[192.168.99.1]:5701, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5701], bind any local is true
May 11, 2016 10:39:47 AM com.hazelcast.spi.OperationService
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Backpressure is disabled
May 11, 2016 10:39:47 AM com.hazelcast.spi.impl.operationexecutor.classic.ClassicOperationExecutor
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Starting with 4 generic operation threads and 8 partition operation threads.
May 11, 2016 10:39:47 AM com.hazelcast.system
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Hazelcast 3.5.2 (20150826 - ba8dbba) starting at Address[192.168.99.1]:5701
May 11, 2016 10:39:47 AM com.hazelcast.system
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Copyright (c) 2008-2015, Hazelcast, Inc. All Rights Reserved.
May 11, 2016 10:39:47 AM com.hazelcast.instance.Node
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Creating MulticastJoiner
May 11, 2016 10:39:47 AM com.hazelcast.core.LifecycleService
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Address[192.168.99.1]:5701 is STARTING
May 11, 2016 10:39:50 AM com.hazelcast.cluster.impl.MulticastJoiner
INFO: [192.168.99.1]:5701 [dev] [3.5.2]
Members [1] {
Member [192.168.99.1]:5701 this
}
May 11, 2016 10:39:50 AM com.hazelcast.core.LifecycleService
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Address[192.168.99.1]:5701 is STARTED
May 11, 2016 10:39:50 AM com.hazelcast.partition.InternalPartitionService
INFO: [192.168.99.1]:5701 [dev] [3.5.2] Initializing cluster partition table first arrangement...
May 11, 2016 10:39:50 AM example.TestApplication
INFO: Cluster ready, starting verticle deploy
May 11, 2016 10:39:52 AM server.js
INFO: vertxStartAsync
May 11, 2016 10:39:53 AM example.TestApplication
INFO: Done
UPDATE: I think that, in this case (and mostly for everyone else who might be doing the same), you are mainly reading data from the file. If that's the case, you can alternatively start the "server" and launch an asynchronous call to read a file, then have its content available later on. In that fashion you won't be blocking your Event Loop, which is what I think it's happening to you right now.