only the following log is useful,other logs is about the defold update:
com.sun.jersey.api.client.ClientHandlerException: java.net.SocketTimeoutException: Read timed out
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
… 21 common frames omitted
only the following log is useful,other logs is about the defold update:
BTW,I think the caching task is the best solution
I’ve updated the server with a 10min timeout limit now. Please let me know if that helps the success rate.
I will continue with the other fixes as well. I’ll keep you updated.
In fact, in our project the Win32 libraries is much smaller than macOS libraries. Here is the detail info about the google protobuf extension which introduced the build problem:
x86-win32: 12.4 MB
x86_64-win32: 21.2 MB
x86_64-osx: 51.5 MB
It doesn’t help, still timeout all the time.
The Editor 2 has now also been updated to have a 10min timeout.
It should have the sha1: bd8e9b221dc47489fd0ee20a3b2477ed27063c24 in the About box
I recommend adding a timeout option to set to editor2, default to 10 min.
Well, first I would really like to know what the actual problem is, not just randomly change things.
For instance, you mention your MacOSX build works. Then, the Win32 build should only be longer by the amount that it builds, which should be ~1-2 minutes. We’ve now upped the timeout with both 5 and 9 minutes!
Could this have anything to do with your VPN service? E.g. are there any settings you can configure there? E.g. timeout values?
What upload/download speed do you get?
Now, with this release (1.2.133), the build server supports building with Clang 6.
This allows for much faster (actual) build times (a few seconds).
You can enable it by adding this to your
platforms: x86-win32: context: use-clang: true x86_64-win32: context: use-clang: true
If you don’t use an app manifest already, you can add this to your
[native_extension] app_manifest = /game.appmanifest
Please note that it doesn’t improve the upload/speeds. we are working on adding a file cache to the server to improve the turnaround times.
A building error in release version 1.2.133 with Clang 6
One of the new team member was stopped by this issue for several days. I can not help, the only thing to do is trying some more tests and showing you the feedback. Hopes you can get the point.
The uploading speed is about 100~150KBs during these tests.
bundle IOS application within 14 minutes
prepare local data without uploading 18:01 ~ 18:04
uploading data to server 18:04 ~18:13
uploading finished and application is ready: 18:13 ~ 18:15
bundle andriod application within 15 minutes
prepare local data without uploading 19:47 ~ 19:52
uploading data to server 19:52 ~20:20
uploading finished and application is ready: 20:20 ~ 20:22
bundle windows application without an ending
prepare local data without uploading 20:03 ~ 20:07
uploading data to server 20:08 ~ 20:16
uploading finished and application is ready: 20:16 ~ nerver(I had waited for more than 20 minutes here and nothing happens even without a timeout indication like the building process)
If the bundle process is similar to the build process, then the issue is not releated to network status. Would you please take a look at the logs on your build server? At least we shall know what happens during these tests.If the single building step for windows target is successful and longer than other target, you can also show us the detailed time cost.
Maybe I can remove some native extentions to findout the critical point where the project could be built for windows tomorrow.
Have you tried building with clang instead? As mentioned here: Defold 1.2.133 has been released
You mean that this is the time before you see anything being sent to build.defold.com?
This is both upload of extension code, the build process on the server and then download of custom engine?
Is this from when you don’t see any more network traffic and the editor does the bundling of the app?
We did tried the clang6 and got some building errors like A building error in release version 1.2.133 with Clang 6.
From these bundle tests, it seems to show three steps.
In the first step, the editor is preparing for some resource data. During this period, there is no obvious network traffic.
The building report also showes more details:
In the second step, the upload is continued for about 8 miutes. According to the uploading rate, about 860100KB = 48MB data(libs or source codes) is sent to the server.
In the third step, the building and linking is processed on the server without network traffic. Finnally, the result program(about 8MB) is sent back from the server at speed 500KB/s (due to the company network download limitation configuration).
When did the same test for macos application on MAC OS, the uploading speed is about 2~3 times faster than the test on windows. Are there any differences in the uploading when bundle the MAC application from different editors?
That is quite a lot, especially at the upload speeds you mention. @Mathias_Westerdahl, ideas on how to reduce amount of upload? Upload only diffs and cache on the server?
There is no difference in how we perform the upload on mac vs windows. Have you tried doing a general internet upload/download speed test on mac and windows? For instance, if you’re on wifi it could be that the windows machine chooses some other encryption method or doesn’t support 5g or whatever. Not saying that’s the case for you.
Here is the general network test result from the speedtest website for our working environment. The uploading rate is the same on MAC(wifi connection) and Windows(ethernet connection).
Is there any hint that why the windows editor only can reach a half(about 100KB/s)?
It is very likely outside our control. I’m assuming that the upload code is the same between the two platforms (the editor is after all cross platform using a single code base), although the underlying implementation (which we don’t control) could be different.
I had made another bundle test on windows in the early morning before most guys coming to the office. It does work better then at normal working time.
The highest uploading rate now almost get the same result as the test made in the browser yesterday.
There are also some wireshark capture records showing the same result. When upload raw source code files(small size), the performance is dropped duo to the packet size.
Raw source code files
33 files with size 122432 bytes with 33 TLS communication rounds within 1 seconds.
A single lib
1 file with size 543411 bytes with 33 TLS communication rounds within 2 seconds.
The pure building and linking on the server only cost about 40+ seconds, this shall not be the cause for the timeout. Definitely we still needs to add more extentions in the project, and then we will see when this timeout issue comes again.
Thank you for getting back to us with additional details! We will start looking into caching of uploads so that you don’t have to upload everything for each rebuild. @Mathias_Westerdahl and @nasthu will start design and implementation of this very soon.
Hopes to see this wonderful feature soon.
Finally the IT department helps to release to limitaion on the uploading rate. Now I get a pretty good uploading test result.
When bundle the application, the uploading rate does only have little improvement.
There is an explicit stop in the uploading that in each 4 packet. Looks like the sending continues for 50ms with 4 packet(16K, TLS max record size) and wait for 180ms. The maxmum uploading speed is 278KB/s.
Would you please take a look at the socket sending buffer size(editor) and socket receiving buffer size(server) ? Maybe chage the default value from 16K to 64K can make sense for large uploading data,
Make an issue for that on the github?