제 에디터에선 notepad가 안나와요

(사진)우클릭 하시고 Notepads 한번 해보시겠어요?

api 요청 횟수와 시나리오 갯수에 대해 질문 있습니다.

결론부터, 해당하는 조건에 명확하게 몇번의 api가 실행되는지는 단정할 수 없습니다.단, 다음과 같이 어느정도 예상은 해볼 수 있습니다. 1초당 3명의 가상 유저를 생성하게 되고, 30초 동안 총 90명의 가상 유저를 생성하게 됩니다.각 시나리오에 (현재 2개) 가상 유저를 배정해야 하는데, Artilleryt에서는 비균등하게 배치가 되고 있습니다. 각 시나리오가, 42유저/48유저 (시나리오1/시나리오2) 만큼 배치되었다고 가정 해보면 다음과 같습니다.1번 시나리오 : 42 * 3 (유저 x api 갯수) = 총 126개의 api 호출2번 시나리오 : 48 * 1 = 48개의 api 호출이런식으로 가정해서 확인해볼 수 있습니다.(사진)config: target: 'http://localhost:8080' phases: - duration: 30 arrivalRate: 3 name: Warm up scenarios: - name: "login and use some functions" flow: - post: url: "/login" - get: url: "/some-function-one" - get: url: "/some-function-two" - name: "just login" flow: - post: url: "/hello" weight 같은 가중치를 줘서 최대한 균등하게 배정하는 방법또한 소개되는것으로 확인되는데, 정확하게 동작하는지는 저도 테스트는 안해보았습니다.https://www.artillery.io/docs/reference/test-script#scenario-weights

Spring REST Docs 관련 질문 사항

비슷한 생각을 가진 여러 수강생에 남겨주신 질문 확인하였습니다! 감사합니다~

세션 타임아웃과 refresh token

저도 동일하게 궁금해서 정리한 개인적인 의견을 한번 공유드립니다. (개인 의견 가득)1. 탈취되었을때를 가정하여, accessToken이 탈취될 경우, 지속적인 유효기간 연장 작업으로, 탈취자는 무한정 접근 권한을 가질 수 있습니다. 이는 보안이슈로 큰 문제가 될 것으로 생각됩니다. - 본 강의에서 나오는 session 타임아웃 연장 또한 같은 문제 있을 것으로 생각. 현업에서는 동일한 방식으로 연장 하는지, 새로운 session을 생성하는지는 저도 의문입니다.2. 1번의 보안이슈를 해결하기 위해서, 로그인시 발급한, refresh token으로 새로운 access token을 발급하여 client에게 전달합니다. 이때 이전에 발급한 access token은 사용이 불가능 합니다. - 짧은 expired time을 설정하여, 이미 발급된 access token이 탈취당한 상황을 우려, refresh token을 사용하여 새로운 인증token을 발급하여 보안이슈 회피 - 기존 사용하던 AccessToken은 ExpiredTime이 다되서 당연히 사용 불가. (탈취된거? 사용 안돼!)결론)결국 refresh token을 적용하게 된 이유는, 사용자 경험성 증가를 위해, 긴 로그인 시간을 지원하게 하고, 보안 이슈를 해결하기 위해 적용되었다고 생각합니다.같이 토론해주세요!

unlock()에 synchronized를 걸면 왜 무한루프를 도는지가 이해가 안됩니다..ㅠㅠ

현재 SpinLockBad class의 lock(), unlock() 메서드는해당 클래스의 private volatile boolean lock을 true 혹은 false로 변경시키면서 lock을 제어하고 있습니다. 하지만, synchronized를 사용하게 되면, 내부 락을 따로 사용하게 되는거죠. 여기서 synchronized를 통해 사용되는 lock 은 lock(), unlock() 메서드에 상관없이 메서드가 시작할때 내부 락을 획득 시도, 끝날때 내부 락을 반납 하게 됩니다. 결국, 해당 SpinLockBad 클래스는volatile boolean 타입 lock 하나synchronized 키워드를 통해 제어하는 내부 lock 하나이렇게 두가지 lock을 사용하게 되서 문제가 발생하게 된거죠.

unlock()에 synchronized를 걸면 왜 무한루프를 도는지가 이해가 안됩니다..ㅠㅠ

main코드가 있어야 확인이 가능할 것 같은데, 현재 확인된 코드로는 lock 전략이 두가지 설정되어있는 것 같습니다.volatile lock , synchronized lock synchronized 키워드를 사용해서 락 전략을 실현하면, 해당 클래스의 내부 lock을 사용하게됩니다.이 lock은 synchronized키워드가 붙은 메서드 or 임계영역 이 완료될떄까지 lock을 반납하지 않습니다. volatile lock으로 lock()/unlock() 메서드를 사용하여 락을 제어한다고 해도, synchronzed 의 내부 락은 반납하지 않기때문에, 질문에 있는 무한 대기 상태가 걸리는 것으로 예상됩니다. 공식 답변이 아니라서 틀릴수도 있는점 양해 부탁드립니다.

List인터페이스를 sout 할때 질문입니다.

저도 질문글 보니 궁금해서 디버깅하면서 뒤져봤네요.결론적으로는 AbstractCollection 클래스의 의 toString 메서드를 사용하는게 맞습니다.List list = new LinkedList(); list.add("data1"); System.out.println("list = " + list);list를 문자열로 반환하기 위해서 String class의 valueOf 실행.여기서 Object의 toString 메서드 실행.toString 실행 시, 해당 Object의 오버라이딩 된 toString, AbstractCollection.toString 실행이런 순서로 이뤄지는걸로 확인하였습니다.

회원목록 열람 실패 해결관련 문의사항

Member 클래스 내 getId, getName 매서드alt+insert -> getter and setter로 재생성 후 문제 해결