Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No enough disk space on this ssaplayground deployment #21

Open
katsusan opened this issue Dec 29, 2023 · 10 comments
Open

No enough disk space on this ssaplayground deployment #21

katsusan opened this issue Dec 29, 2023 · 10 comments

Comments

@katsusan
Copy link
Member

image

As no share support yet, a monthly or yearly routine for clearing up the buildbox is OK.

@katsusan
Copy link
Member Author

@changkun

@changkun
Copy link
Member

Good idea. Let's implement the feature:

  1. Record those that created a share link
  2. Daily clean for those that are not shared.

@changkun
Copy link
Member

I just wiped some of the log files in the instance; it should be fine now.

@katsusan
Copy link
Member Author

I have some initial plans regarding what we need to do next:

1). add Share button and binding action to request for /share api.

image

a. for user code which haven't been executed yet, the location.href should be
https://golang.design/gossa', share would be a post action and take
the code as payload, then redirect user to golang.design/gossa?id=xxxx.

b. for the code already executed, the location.href would be like
https://golang.design/gossa?id=22d7d46f-a63c-11ee-ac09-xxxx, which already
has the code path in it, just post the id to backend.

2). add /share route,

  • if payload has usercode, then make a directory public/share/[id] for it.
  • if payload only has id, then move the public/buildbox/[id] to /public/share/[id].

3). when user access golang.design/gossa?id=xxxx, first check /public/share then /public/buildbox.
Here we define the buildbox path as the temporary directory holding user session files, which can be
wiped out when the session ended.(TODO: It is somewhat tricy as we don't know when user closed his
tab).

Welcome for your thoughts on it.

@changkun
Copy link
Member

Overall, it sounds deliberative to me.

@katsusan
Copy link
Member Author

katsusan commented Jan 3, 2024

Maybe my thoughts seem a little tedious:D. The core idea is to divide the original public/buildbox into two parts: one for user session and the other for user share.

// 可能我表述的不太清楚(英语水平有限--), 核心做法大概是把原本的存放在buildbox的用户文件夹按照生命周期分成两类:
// - 一类仅在用户session为active时有效, 当用户关闭tab后可以随意清理.
// - 另一类是用于share功能, 在承诺的时长内不会被清除掉.
// 现在有个困扰是需要user关闭tab的消息来告知后端,目前搜到的方法是beforeunload事件,但不是专业前端没办法系统评判.
// 不知道changkun兄有什么想法可以指教下.

@changkun
Copy link
Member

changkun commented Jan 3, 2024

用户状态的判定可能过于复杂,实现成本较高。

我比较倾向于增加一个share按钮:

  1. 点击 build 按钮,显示 ssa,但地址栏不需要进行调整(即不暴露UUID,也不在后台做任何记录,如果不点击分享按钮,会在第三步被清理)
  2. 点击 share 按钮,在地址栏和 share 按钮旁显示 UUID 地址,后台同时保存此 UUID 到一个文本文件(可以考虑用 lockfile 来避免使用数据库)
  3. 实现一个后台清理 goroutine,定期 diff 所有的文件夹和点击过保存的 UUID,删除没有被保存过的

@katsusan
Copy link
Member Author

katsusan commented Jan 4, 2024

Agree.

关于第三点的定期清理有时候会产生意外的影响,以我个人为例,有时在研究某段代码时来了更重要的任务,
可能要放在浏览器tab那里隔几天后再重新pick回来,这时候如果服务器端没有任何记录(地址栏url也没有重定向)
而且中间可能要经历浏览器更新重启等一系列操作(chrome日常),代码片段就相当于丢失了.
这个可以参考godbolt.org的做法将代码存放在浏览器的localStorage中解决.

@katsusan
Copy link
Member Author

Ok, I may pick up this task during Spring Festival if you dont't have enough time.

BTW, the go version of ssaplayground need to be updated to newer go release. As every
major version update might come with new runtime/compiler features, it should keep up with
newest major version at least.

@changkun
Copy link
Member

Thanks for picking it up.

I think it is worth a separate issue to track how to solve automatic major version updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants