偶现编译失败，重启后成功 about xmake HOT 14 OPEN

Bot detected the issue body's language is not English, translate it automatically.

Title: Compilation fails occasionally, but succeeds after restarting

from xmake.

加 -vD 给完整 logs

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Add -vD for full logs

from xmake.

[2024-03-06 11:44:03]fallback to the local cache, @programdir/modules/private/service/stream.lua:303: >: recv timeout!
[2024-03-06 11:44:03]stack traceback:
[2024-03-06 11:44:03] [C]: in function 'error'
[2024-03-06 11:44:03] [@programdir/core/base/os.lua:957]: in function 'raiselevel'
[2024-03-06 11:44:03] [@programdir/core/sandbox/modules/utils.lua:149]: in function 'assert'
[2024-03-06 11:44:03] [@programdir/modules/private/service/stream.lua:303]: in function 'recv'
[2024-03-06 11:44:03] [@programdir/modules/private/service/stream.lua:334]: in function 'recv_header'
[2024-03-06 11:44:03] [@programdir/modules/private/service/stream.lua:344]: in function 'recv_data'
[2024-03-06 11:44:03] [@programdir/modules/private/service/remote_cache/client.lua:266]: in function 'existinfo'
[2024-03-06 11:44:03] [@programdir/modules/private/cache/build_cache.lua:47]: in function '_get_existinfo'
[2024-03-06 11:44:03] [@programdir/modules/private/cache/build_cache.lua:245]:
[2024-03-06 11:44:03]
[2024-03-06 11:44:03]

[2024-03-06 11:44:03]error: @programdir/core/base/scheduler.lua:183: assertion failed!
[2024-03-06 11:44:03]stack traceback:
[2024-03-06 11:44:03] [C]: in function 'assert'
[2024-03-06 11:44:03] @programdir/core/base/scheduler.lua:183: in function 'base/scheduler._poller_resume_co'
[2024-03-06 11:44:03] @programdir/core/base/scheduler.lua:241: in function 'base/scheduler._poller_events_cb'
[2024-03-06 11:44:03] @programdir/core/base/scheduler.lua:1074: in function 'base/scheduler.runloop'
[2024-03-06 11:44:03] @programdir/core/main.lua:310: in function 'main.entry'
[2024-03-06 11:44:03] (...tail calls...)
[2024-03-06 11:44:03]make: *** [center_query] Error 255
[2024-03-06 11:44:03]
[2024-03-06 11:44:03]real 0m43.444s
[2024-03-06 11:44:03]user 0m34.237s
[2024-03-06 11:44:03]sys 0m19.024s

from xmake.

recv 超时了，可以重启下服务端，超时配置调大点试试。。

另外，dev 我加了点 log 和兼容逻辑，可以更新后，再试试，如果还有，再给份 -vD logs

xmake update -s dev

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

If recv times out, you can restart the server and try increasing the timeout configuration. .

In addition, I added some logs and compatibility logic to dev. You can try it again after updating. If there is still something left, give me a copy -vD logs

xmake update -s dev

from xmake.

远程服务并没有设置超时时间 client是15s 超时的失败率和缓存的大小应该有些关系 50G以下没有出现过这个问题 50~100G开始偶现 150G开始频繁出现 编译三次两次都可能会出现这个问题 将缓存目录所有缓存全部rm后 编译恢复正常 没有再出现这种问题 是否是搜索缓存导致的问题？

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

The remote service does not set a timeout time. The client is 15s. There should be some relationship between the timeout failure rate and the size of the cache. This problem has not occurred below 50G. From 50 to 100G, it has occasionally occurred. From 150G, it has frequently occurred. This problem may occur after compiling three times and twice. After rm of all caches in the directory, the compilation returned to normal and this problem did not occur again. Is it a problem caused by the search cache?

from xmake.

应该是服务端 cache files 的文件组织，我没像本地 cache 那样，分两级存储，并且用了 os.files 遍历，所以获取 cache file 的效率，随着文件数增多，变慢导致。。

回头我优化下

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

It should be the file organization of server-side cache files. I did not store it in two levels like the local cache, and used os.files traversal, so the efficiency of obtaining cache files slowed down as the number of files increased. .

I'll optimize it later

from xmake.

不对，刚看了下，文件存储已经是分两级存储，直接索引了，如果io还是慢，这边也没啥好的办法继续优化

from xmake.

你这 150G 是一次编译的结果，还是跑了 N次构建，或者几天的。。或者可以加个闲时清理策略，确保存储控制在一定量级内。也许能缓解下

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

No, I just took a look and found that file storage is already divided into two levels and indexed directly. If io is still slow, there is no good way to continue optimizing it.

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Is your 150G the result of one compilation, or N builds, or several days? . Or you can add a free-time cleanup policy to ensure that storage is controlled within a certain level. Maybe it can be relieved

from xmake.