google cloud(https://console.cloud.google.com/) 에 만들어 놓은 project 의 owner 계정이 사라지면 project 는 같이 지워질까?
개인 계정인 경우는 그렇다.
그러나 google workspace 같은 경우라면 다르다.
springboot / vscode 에서 java 사용 / --debug-jvm / unittest system.out / stdout 출력
잠깐 써본 소감은 'Language Support for Java' 의 memory 를 max 2G까지 올렸는데, 그래서인지 메모리를 많이 잡아먹었다. 그러나, IntelliJ를 사용할때와 비슷한 수준이었다.
여기선 workspace setting 을 변경했다.
// myproj.code-workspace
{
"folders": [
{
"path": ".."
}
],
"settings": {
"java.jdt.ls.java.home": "d:\\a\\appss\\jdk-17.0.6.10-hotspot"
}
}아래 그림처럼 gradle 의 task 를 실행할 수 있다. 여기서 debugger 를 run 하거나, 그냥 run 하거나 할 수 있다.
아직은 gradle extension 에서 개별 class의 test 에 대한 debug mode run 은 지원이 안된다.
그래서 다음과 같은 방법으로 gradle test 에 debugger 를 붙일 수 있다.
gradlew test --tests co.my.pro.MyTests --debug-jvmlaunch.json을 설정해서 debugger를
실행(f5)시킨다.// launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "java",
"request": "attach",
"name": "Attach by Process ID",
"processId": "${command:PickJavaProcess}"
}
]
}
--debug-jvm: Testing in Java & JVM projects
testLogging.showStandardStreams = true 을 해주면, log 가
stdout 으로 찍힌다.
events=["passed", "failed", "skipped", "standard_out", "standard_error"]로 설정하는 것은
events=["passed", "failed", "skipped"]
showStandardStreams = true과 같다. showStandardStreams 은
events=["standard_out", "standard_error"] 과 같다. 위와
같이 설정하면 2개가 동시에 적용된다.
test {
useJUnitPlatform()
// set systemProperties with default value "spring.profiles.active=test"
systemProperties = System.properties
if (!systemProperties.containsKey('spring.profiles.active')) {
systemProperty("spring.profiles.active", "test")
}
testLogging {
events=["passed", "failed", "skipped", "standard_out", "standard_error"]
// events=["passed", "failed", "skipped"]
// showStandardStreams = true
}
}credential: 'include' 동작만약 a.domain.net, b.domain.net 이 모두 Domain을 자신들의 상위 도메인인 .domain.net 으로 해서 Set-Cookie 를 날리는 상황을 가정해보자.
a.domain.net : Set-Cookie: session=11111111111; path=/; domain=.domain.net; HttpOnly
b.domain.net : Set-Cookie: session=22222222222; path=/; domain=.domain.net; HttpOnly
A라는 사이트에서 login 은 해서 cookie 가 만들어졌다. 이때 credential 을 include 하면 이 cookie 가 request 시점에 날라간다.
이 때 B라는 사이트에서 login을 한다. 그런데 같은 domain 에 대해서 만들기 때문에, A 라는 사이트에서 사용하던 cookie 가 browser에서 지워지고, 새롭게 B site 에서 사용할 cookie 가 만들어진다.
cookie 는 도메인 별로 unique 하게 존재하지만, 이것을 해당 domain 외의 domain 에서 access 하는 것 또한 same-origin policy 를 따라야 해서, browser에서 다른 site A로 request를 보낼때 credential(cookie)이 없는 채로 날라간다.
즉, domain 설정을 잘 해줘야 2 site 에서 동시에 cookie 를 사용할 때 문제가 없다.
Set-Cookie 의 domain설정을 해서 테스트해 볼 수 있다.백본망 / 백본은 뭔가?
일반적으로 ref.1 에 나와있듯이 ’주요 노드(primary nodes)를 연결하는 고용량 통신 시설(high capacity communication facilities)’을 가리키는 용어이다.
기본적으로 backbone network 는 개념적인 이야기다. 그러므로 일반적인 뜻보다는 좀 더 작은 용량의 시설도 sub-network들을 연결한다면 백본망이라 부를 수 있다.
만약 내가 ISP 로 부터 인터넷 선을 하나 할당받고, 이것을 허브를 이용해서 사무실 2개에 대해 각각 케이블을 뽑고, 그 케이블마다 공유기에 연결해서 각각 network 를 구성했다고 하자. 그렇다면 나의 백본망은 이 NAT 와 각 사무실로 뻗어나가는 2개의 유선일 것이다.
ISP 의 백본은 우리가 일반적으로 생각하는 백본이라고 생각하면 될 것 같다. 다음 기사를 통해 대략적으로 어떻게 구성되어 있는지 확인해 볼 수 있다.
국내 최초로 5G 백본망에 메시(Mesh) 구조 적용 < 네트워크 < AI Industry < 기사본문 - 인공지능신문, 2019-02-13
KT 아현 국사 화재로 본 통신사업자의 바람직한 망 구조는? | NETMANIAS, 2018-12-12
스프링 / 스케쥴러 / scheduler / celery
기본은 8000 이다. localhost:8000/dashboard
로 가면 JobRunr 의 dashboard를 확인할 수 있다. 다음처럼 config file 에서
변경할 수 있다.
org.jobrunr.dashboard.enabled=true
org.jobrunr.dashboard.port=8000매분마다 도는 job 을 설정해놨다. 그러고 나서, 보니 같은 시점에 2개가 실행됐다. 그래서 db 의 jobrunr_jobs 에서 확인을 해보니, 같은 시간에 2번이 실행됐다.
created_at 을 보니, 매 분마다 실행시간이 조금씩 밀렸다. 대략
0.08s~0.09s 씩 늦어졌다. 그래서 결국 같은 시점에 2번이
실행되는 상황이 왔다.
위의 5초단위의 pollingTimeInterval 과 어느정도
상관관계가 있는 듯도 싶다. 만약 항상 40~50초 시점에 trigger 가 발생한다면, job 내에서 시간을 보정해서 사용하는 것도 방법일 듯 하다.
-- 같은 '분'(minute)에 실행된 job 들
SELECT * FROM (
SELECT count(his) cnt, t1.* FROM (
SELECT DATE_FORMAT(createdAt, '%j %H:%i') AS his, DATE_FORMAT(createdAt, '%H:%i:%S.%f'), createdAt, updatedAt
FROM jobrunr_jobs
WHERE recurringJobId
IN('myjob.MyJobBackgroundJobProcessor.runEveryMinuteExample()')
ORDER BY createdAt DESC
) AS t1
GROUP BY t1.his
) AS tt1 WHERE cnt > 1
;| createdAt | updatedAt |
|---|---|
| 2024-02-13 04:21:59.615 | 2024-02-13 04:21:59.696 |
| 2024-02-13 04:22:59.715 | 2024-02-13 04:22:59.793 |
| 2024-02-13 04:23:59.812 | 2024-02-13 04:23:59.880 |
| 2024-02-13 04:24:59.904 | 2024-02-13 04:24:59.988 |
| 2024-02-13 04:26:00.016 | 2024-02-13 04:26:00.393 |
| 2024-02-13 04:26:45.418 | 2024-02-13 04:26:45.494 |
| 2024-02-13 06:39:59.635 | 2024-02-13 06:39:59.706 |
| 2024-02-13 06:40:59.726 | 2024-02-13 06:40:59.793 |
| 2024-02-13 06:41:59.812 | 2024-02-13 06:41:59.885 |
| 2024-02-13 06:42:59.910 | 2024-02-13 06:42:59.976 |
| 2024-02-13 06:44:00.001 | 2024-02-13 06:44:00.327 |
| 2024-02-13 06:44:45.314 | 2024-02-13 06:44:45.358 |
| 2024-02-13 08:54:59.536 | 2024-02-13 08:54:59.603 |
| 2024-02-13 08:55:59.625 | 2024-02-13 08:55:59.695 |
| 2024-02-13 08:56:59.723 | 2024-02-13 08:56:59.804 |
| 2024-02-13 08:57:59.820 | 2024-02-13 08:57:59.887 |
| 2024-02-13 08:58:59.913 | 2024-02-13 08:58:59.980 |
| 2024-02-13 09:00:00.020 | 2024-02-13 09:00:03.025 |
| 2024-02-13 09:00:46.289 | 2024-02-13 09:00:46.723 |
만약 다음처럼 정의를 하면,
@Recurring(cron = "*/10 * * * *", zoneId = "Asia/Seoul")job 은 다음처럼 10분 근처에서 실행한다. 30분에 대한 trigger 가 29:54 쯤에 발생한다.
| createdAt | updatedAt |
|---|---|
| 2024-02-17 07:29:54.207 | 2024-02-17 07:29:54.239 |
| 2024-02-17 07:19:53.956 | 2024-02-17 07:19:53.983 |
| 2024-02-17 07:09:53.689 | 2024-02-17 07:09:53.798 |
Start recurring jobs multiple times? · jobrunr/jobrunr · Discussion #755 · GitHub
google cloud credential / api credential / access token
OAuth 2.0 은 유저들이 application 과 특정data 를 공유할 수 있게 해준다. 공유하면서도 그들의 user명과 비밀번호와 다른 개인정보를 노출하지 않는다.
예를 들어 OAuth 2.0 은 user의 Google Drive에 file 을 저장하기 위해 그 해당 user로 부터 permission(허락)을 획득하게 된다.
OAuth 2.0 flow 는 implicit grant flow (암묵적 허락 흐름)라고 부른다. 이것은 ’user 가 application 에 있을때만 API들에 접근’하는 application들을 위해 만들어졌다. 이 application들은 기밀정보(confidential information)를 저장해 놓을 수 없다.
me: 그래서 access token 만 처음에 받아와서 사용하게 된다. app 등은 Authorization Code 를 받아온 후에 다시 access token 을 받는다. 다음 글들을 읽어보면 된다. Using OAuth 2.0 for Web Server Applications 를 봐도 알 수 있는데, 이것은 confidential information 을 저장해 놓고 사용하는 app을 위해 design 됐다고 나와 있다.
이 flow에서, app 은 query parameter를 이용하는 Google URL 을 연다. 이 query parameter 는 app 을 구별하고, app 이 필요한 API 접근의 종류를 구별하는 값을 갖고 있다.
현재 브라우저 window 에서 이 URL 을 열거나 popup 으로 열 수 있다.
user 는 Google 에서 인증하고, app이 요청하는 permission 들을 grant 해주게 된다. Google 은 그리고 나서 user 를 app 으로 다시 redirect 시킨다. 이 때 access token 와 함께 redirect 시킨다. app 은 이 access token 을 확인(verify)하고, API 요청을 만들때 사용된다.
Google API들에 access 하기 위해서 OAuth 2.0 을 사용하는 모든 application은 authorization credential들을 가져야만 한다. 이 authorization credential 은 Google 의 OAuth 2.0 server 가 application 을 판별할 수 있게 해준다.
이 credential id 는 다음 link 에서 만들 수 있다.
여기서 authorized JavaSCript origins 를 설정하게 된다. 이 설정된 origin 에서 보내는 request 만 accept 하는 것이다.
위의 글의 내용은 요즘 브라우저에서 3rd party cookie 를 없애려는 움직임이 있다. 그런 이유로 implicit grant flow 는 더이상 auth 를 하는 방법으로 적절치 않다는 이야기다.
스냅샷
금액 정보 : Archive Amazon EBS snapshots - Amazon Elastic Compute Cloud