Kevin의 알기 쉬운 Spring Reactive Web Applications: Reactor 1부
안녕하세요. Backpressure의 Drop 전략에서 버퍼가 비워질 때까지 Emit된 데이터가 Drop이 된다는 것은 이해했습니다. 그런데 1번 데이터가 subscriber에게 전달되어서 처리가 되면 버퍼에 자리가 한 자리 비게 되는데 왜 데이터가 계속 Drop이 되는건가요? (코드 실습에서 onNext()함수가 호출이 되어도 255,256,257 ~ 1024까지 모두 드랍됨) | 1, 2 | <-------- 3 듣랍 | 2, |. <-------- 4 드랍 (여기서 왜 4번 데이터는 안들어가나요?) | 5, 6 | Buffer DROP-LATEST를 보면 | 1, 2 | <---- 3들어오는 중 버퍼 가득 차서 drop | 2, 4 | <------ 1번이 버퍼에서 나가고 한 자리가 비어서 4번이 들어와짐 이런식으로 동작을 하는데 Drop은 이렇게 동작하지 않는 것 같아 버퍼가 어떻게 동작하는지 궁금하여 질문드립니다.
실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)
강사 님께서는 객체를 인스턴스화 하실 때, 생성자를 사용하거나, 정적 팩토리 메서드를 사용하는 방식 2가지를 이용하셨는데 혹시 코틀린에서 builder 패턴을 사용하는건 어떻게 생각하시나요?? defalut 파라미터를 이용하고 naming을 통해 builder패턴 처럼 사용할 수 는 있겠지만 java에서 builder패턴을 통해 객체를 만들었던 것에 비하면 불편하다는 생각이듭니다. 조언 해주시면 감사하겠습니다.
theme 적용시, 강사님께서 말씀해주신 것처럼 작업 폴더에 .streamlit 폴더를 만들고, 그 안에 config.toml 파일을 만들어 테마 적용을 했지만, 아래의 문구가 발생하며, 태마가 적용이 되지 않습니다. The page that you have requested does not seem to exist. Running the app's main page. 어떤 이유 인지 알려주세요.
안녕하세요, 강의를 보고 공부를하다 궁금한 점이 생겨 질문드립니다. 제가 예측한 강의 내용으로는, "경쟁 상태 예시(재고 수량)에 대하여 레디스 를 활용한다." 라고 예측 했습니다. 이에 대하여, "레디스는 싱글 스레드 기반이니깐, 락킹 없이 해당 작업이 가능할 것" 이라고 추측하였는데요, 그러나 제가 생각지 못한 레디스 lock 과 관련된 내용을 접하게 되어 신기하면서도 또 궁금한 부분이 생겨 질문드립니다. 레디스 락 전략이 사용되는 이유와 예시를 조금더 들어볼 수 있을까요? 혹은 이와 관련하여 추가적으로 공부해볼 수 있는 자료를추천해주시면 감사하겠습니다.
갱신된 강의자료에도 나와 있듯이, fetchResult, fetchCount 등의 메소드는 deprecated 예정입니다. 또한 해당 메소드는 Page 타입을 반환하기 때문에 Page 타입을 직접적으로 조작해야 한다는 제약이 있습니다. 이걸 잘 쓰면 되는데, Page 의 시작번호 등 제약도 있어서 저는 회사에서 Page 를 따로 만들어서 사용하거든요. 그래서 search 메소드와 count 메소드는 항상 분리하고 있습니다. 2. 그런 점에서 count 만 최적화하는 로직만 베껴서 만든 최적화 메소드입니다. 실제로 count 구문을 실행하기 위한 메소드입니다. 필요에 따라서 public 으로 만들어도 될 것 같네요. // count 실행 메소드 private Long countByCond(MemberSearchCond cond) { return query .select(member.countDistinct()) .from(member) .where( usernameEq(cond.getUsername()), teamNameEq(cond.getTeamName()), ageGoe(cond.getAgeGoe()), ageLoe(cond.getAgeLoe()) ) .fetchOne(); } 최적화 로직을 베낀 메소드입니다. 스프링 데이터 JPA 는 아래 코드와 같이 page, size 값이 null 이 아니고, 적절한 범위에 있는지를 판단하여 isPaged 라는 분기를 만듭니다. 참고로 코드를 분석하면서 내린 뇌피셜이니 혹시 틀리다면 말씀해주세요. page 가 0 이 아니라 1 부터 시작하는 건 제 취향입니다. 회사에서 그렇게 쓰고 있거든요. 필요에 따라 0 부터 시작하도록 바꾸는 건 어렵지 않을 것 같습니다. public Long countByCondOptimization(List<?> content, MemberSearchCond cond, Long page, Long size) { boolean isPaged = page != null && size != null && page > 0 && size > 0; long offset = isPaged ? (page - 1) * size : 0L; long contentSize = content.size(); if (!isPaged || offset == 0) { if (!isPaged || size > contentSize) { return contentSize; } return this.countByCond(cond); } if (contentSize != 0 && size > contentSize) { return offset + contentSize; } return this.countByCond(cond); } 이렇게 하여 count 쿼리를 리스트 조회 쿼리와 분리하여 재사용성을 높이면서, 성능도 최적화할 수 있습니다. 감사합니다.
강의에서는 Query DSL 4.x 버전이어서 제네릭 없는 예제 코드인 것 같은데, 제가 올리는 버전은 5.0 버전이어서 차이가 있음을 감안해주세요. 정렬 조건을 하나만 추가하는 코드입니다. 정렬 조건을 여러 개 추가하려면 반복문을 돌면서 JPAQuery 를 동적으로 확장해나가면 됩니다. // 페이징하는 메소드에서 사용 private Expression<? extends Comparable<?>> specifyMemberProperty(String prop) { prop = prop == null ? "" : prop.toLowerCase(); if (prop.equals("username")) { return member.username; } if (prop.equals("age")) { return member.age; } return member.id; } // 페이징하는 메소드 // ... .orderBy(new OrderSpecifier<>("desc".equalsIgnoreCase(dir) ? Order.DESC : Order.ASC, specifyMemberProperty(prop))) .fetch(); -- 저는 일단 이렇게 만들어봤는데, 다른 분께서 더 나은 코드, 더 빠른 코드가 있다면 저한테도 알려주세요. 감사합니다.
@ManyToOne @JoinColumn(name = "parent_id") private Category parent; @OneToMany(mappedBy = "parent") private List<Category> child = new ArrayList<>(); 안녕하세요. 위 코드에서 부모 쪽에 다대일 매핑 한 이유를 알고 싶습니다. 아니면 DB 테이블 안에서 부모 셀프 외래 키를 만들어서 조회할 때 이 외래 키를 참조하여 자식 카테고리들까지 같이 조회하게 만들었기 때문에 테이블에서 다는 parent_id니까 jpa에도 parent에 다를 준 건 가 싶기도 해서요 필드 명에 부모 자식이 있어서 부모는 하나고 자식은 여러 개인데 부모 쪽에 다로 돼있어서 헷갈리네요..
안녕하세요 선생님! 동시성과 병렬성 관련해 기초가 약해 해당 강의를 들으면서 OS 부족한 부분을 많이 알게되어 도움이 많이되고 있습니다. 다름이 아니라 해당 강좌 범위는 벗어나지만.. 구글링해도 명확하게 해결되지 않아 질문 드립니다. 동시성을 구현하는 방법으로 멀티쓰레드 나 코루틴 방법으로 구현을 할 수있고 멀티쓰레드 방법에서 쓰레드 전환 간 context switch가 많기 때문에 오버헤드도 많아 Coroutine 방법을 많이 쓰고 또한 유저가 이벤트루프(스케쥴링)을 app에서 관리한다는 측면에서 디버그가 유용하다 정도로 이해하고 있습니다. 많은 블로그에서 멀티쓰레드보다 코루틴을 소개하면서 동시성 구현시 코루틴을 더 상위(혹은 좋은) 방법으로 서술이 많이 되어 있더라구요. I/O작업이 빈번할 경우 코루틴이 더 유리하다는 이해가 됩니다. 싱글스레드 + async 싱글스레드 멀티스레드 + async 멀티스레드 2개의 구현방법이 레이어가 다르다(thread와 task)보니 4가지 경우의 수를 적용할 수 있는데 실제 동시성을 적용해야되는 상황이면 어떻게 판단하고 최적의 구현방법(4가지 중 선택)을 적용할 수 있을까요? (파이썬 스택을 쓰고 있으며 GIL도 이해하고 있는 상태입니다.) 다시한번 해당 강의와 조금 벗어난 질문드려 죄송합니다. ( _ _ )
