I see … thank you. The problem is that I don’t think I can share the project (company policy). I hope you understand.
Just a quick overview of my setup, I’m working on a Windows 10 machine with Docker Toolbox and instead of running ./backendless_start.sh script to start the services, I use this:
BL_MYSQL_PORT=3306 BL_MONGODB_PORT=27017 BL_PROPERTY_config_redis_bl_debug_port=6380 BL_PROPERTY_config_server_publicPort=9000 BL_PROPERTY_config_console_port=80 BL_PROPERTY_config_rt_server_socketServer_connection_port=5000 REGISTRY=backendless VERSION=6.1.8.mysql8 MOUNTS=/c/Users/bassam/Desktop/Backendless/setup_win/scripts/mounts docker stack deploy -c ./consul-compose.yml bl-swarm && \
BL_MYSQL_PORT=3306 BL_MONGODB_PORT=27017 BL_PROPERTY_config_redis_bl_debug_port=6380 BL_PROPERTY_config_server_publicPort=9000 BL_PROPERTY_config_console_port=80 BL_PROPERTY_config_rt_server_socketServer_connection_port=5000 REGISTRY=backendless VERSION=6.1.8.mysql8 MOUNTS=/c/Users/bassam/Desktop/Backendless/setup_win/scripts/mounts docker stack deploy -c ./pre-configuration-compose.yml bl-swarm && \
BL_MYSQL_PORT=3306 BL_MONGODB_PORT=27017 BL_PROPERTY_config_redis_bl_debug_port=6380 BL_PROPERTY_config_server_publicPort=9000 BL_PROPERTY_config_console_port=80 BL_PROPERTY_config_rt_server_socketServer_connection_port=5000 REGISTRY=backendless VERSION=6.1.8.mysql8 MOUNTS=/c/Users/bassam/Desktop/Backendless/setup_win/scripts/mounts docker stack deploy -c ./backendless-compose.yml bl-swarm && \
BL_MYSQL_PORT=3306 BL_MONGODB_PORT=27017 BL_PROPERTY_config_redis_bl_debug_port=6380 BL_PROPERTY_config_server_publicPort=9000 BL_PROPERTY_config_console_port=80 BL_PROPERTY_config_rt_server_socketServer_connection_port=5000 REGISTRY=backendless VERSION=6.1.8.mysql8 MOUNTS=/c/Users/bassam/Desktop/Backendless/setup_win/scripts/mounts docker stack deploy -c ./coderunner-js-compose.yml bl-swarm
ugly I know … but it’s working for me (for now at least). So, as you can see, I’m mounting the repo folder to my local path on the host machine. I found out, after some research, that this might be causing the slowliness. It’s reported a lot on Docker forums. you can check this thread if you like:
https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076
So, I modified backendless-compose.yml to use a named volume for the repo (so it’s no longer mounted to the host). I also modified coderunner-js-compose.yml to use that volume (repo) as external volume.
After I done that, the slowliness issue is gone. So, now, I’m getting always:
16:14:30.043 Preparing app zip file for deployment..
16:14:38.424 2317 files added into deployment archive
16:14:39.139 Publishing Model to server
16:14:39.173 o296 > POST /servercode/publishcode/JS FormData {
_overheadLength: 255,
_valueLength: 39434446,
_valuesToMeasure: [],
writable: false,
readable: true,
dataSize: 0,
maxDataSize: 2097152,
pauseStreams: true,
_released: false,
_streams: [
'----------------------------837419444683910176349632\r\n' +
'Content-Disposition: form-data; name="model"\r\n' +
'\r\n',
'default',
[Function: bound ],
'----------------------------837419444683910176349632\r\n' +
'Content-Disposition: form-data; name="code"; filename="code"\r\n' +
'Content-Type: application/zip\r\n' +
'\r\n',
<Buffer 50 4b 03 04 0a 00 00 00 00 00 d3 81 8c 51 53 82 ab b5 6d b0 02 00 6d b0 02 00 0a 00 00 00 6d 6f 64 65 6c 2e 6a 73 6f 6e 7b 22 68 61 6e 64 6c 65 72 73 ... 39434389 more bytes>,
[Function: bound ]
],
_currentStream: null,
_insideLoop: false,
_pendingNext: false,
_boundary: '--------------------------837419444683910176349632'
}
16:14:39.198 There will be no more data.
16:14:52.477 o296 < (1): 13301.648ms
16:14:52.518 PUSHING CODE: 13378.581ms
16:14:52.530 Successfully published
16:14:52.532 DONE!!
Done in 24.45s.
The total process is done in 24s instead of what used to be > 60s
After I’m done with that, I deployed my app and kept monitoring the mount repo folder on coderunner-js and noticed that my code was deployed to my PRODUCTION folder. Then, momentarily, it was GONE… then, it came back again and stayed there. So, not sure if the removal of code from PRODUCTION folder is part of the deployment process, but it was gone for seconds. may be this is supposed to happen, but before the workaround, it was not being put back again for some reason on the host machine.
Anyway, I think with this workaround, I should be able to start “development” on that project (and fast). I’ll keep monitoring and see if the problem comes back again.