너구리의 코딩 블로그

[MySQL] Windows 11 MySQL 설치/다운로드 방법

코딩하는 너구리 — Thu, 15 Feb 2024 15:33:08 +0900

MySQL 다운로드

오늘은 Windows 11 버전에서 MySQL 다운로드 하는 방법에 대해서 포스팅하겠습니다.

1. MySQL 홈페이지로 이동

아래 링크를 눌러 mysql 다운로드 페이지로 이동합시다!

https://www.mysql.com/downloads/

MySQL :: MySQL Downloads

www.mysql.com

스크롤을 아래로 내려, MySQL Community (GPL) Downloads » 을 클릭합니다.

다음 화면에서 MySQL Community Server 를 클릭합니다.

설치하기 편한 MSI Installer로 선택해주세요 [ Windows (x86, 64-bit), MSI Installer ]

다운로드 화면에서는 [ No thanks, just start my download.] 를 클릭해주세요

지금부터는 쭉 MSI 실행 화면입니다.

이제부터 설정화면으로 넘어갑니다

MySQL에서 파일 접근에 대한 권한을 받는 부분이니 가급적 Yes를 선택해주세요.

샘플 데이터베이스는 필요 없으므로 Next 선택해주었습니다.

여기까지 MySQL Server 설치는 완료되었습니다. 이제 직접 접근해보도록 할게요.

윈도우 키를 눌러 "MySQL"로 앱을 검색한 뒤 "Command Line Client"를 실행시켜주세요.

실행 후 비밀번호를 입력해야 하는데, 가입 시 설정한 Root Password를 입력해주세요.

실행 화면

이것으로 Windows 11 환경에서의 MySQL 8.3 설치를 마치겠습니다.

[Flutter] Unable to boot simulator 해결 방법

코딩하는 너구리 — Sat, 9 Sep 2023 15:52:28 +0900

앱을 개발하던 중 iOS Simulator가 실행되지 않는 문제가 발생했다.

생각보다 쉽게 해결이 가능했는데, 기기 캐시 데이터를 지워주니 정상적으로 동작했다.

에러 메시지

위와 같이 에러 메시지가 나오며 시뮬레이터가 실행되지 않았다.

해결방법은 상당히 간단했는데 아래와 같이 캐시를 삭제해주면 된다.

1) 저장공간 접속

이 Mac에 관하여 클릭

추가 정보 클릭

저장공간 클릭

[이 Mac에 관하여] 메뉴 클릭 후 > [추가 정보...] 클릭 > 일반 > 저장공간 에 접근해주세요.

개발자 클릭

개발자 오른쪽에 i 마크를 클릭해줍니다.

캐시 삭제

이제 다시 iOS Simulator를 실행해보겠습니다.

성공

실행 성공 !

[AWS] AWS EC2 JDK 17 설치 방법

코딩하는 너구리 — Sat, 9 Sep 2023 15:37:38 +0900

AWS EC2 인스턴스 설치 후 접속하기

AWS linux 서버를 기준으로 2023년 9월 기준 설치 방법입니다.

EC2 접속 화면

JDK 다운로드

서버에 접속한 뒤 JDK 설치부터 진행하겠습니다. JDK는 17 버전을 사용할 예정이며 temurin-jdk17을 다운받아보겠습니다.

sudo yum install temurin-17-jdk

깃허브에서 JDK를 설치할 수 있도록 wget을 먼저 설치합니다.

sudo yum -y install wget curl

wget 설치

깃허브 주소에서 jdk 17 tar 파일을 바로 다운받습니다.

wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.2%2B8/OpenJDK17U-jdk_x64_linux_hotspot_17.0.2_8.tar.gz

jdk-17 tar.gz 설치

tar.gz 파일이 설치되었습니다.

다음으로 해당 파일 압축을 풀고, 이제 필요없는 .tar.gz 파일은 삭제해주겠습니다.

tar -xvf OpenJDK17U-jdk_x64_linux_hotspot_17.*.tar.gz
rm -f OpenJDK17U-jdk_x64_linux_hotspot_17.*.tar.gz

JDK 17 설치 완료

JDK 17 설치가 완료되었습니다.

이제 Java 경로를 지정하고 HOME_PATH를 지정해줍니다.

# JDK 경로 이동
sudo mv jdk-17.* /opt/jdk-17

# HOME_PATH 설정
vi ~/.bashrc
export JAVA_HOME=/opt/jdk-17
export PATH=$PATH:$JAVA_HOME/bin

# 저장 파일 반영
source ~/.bashrc

설치된 자바 HOME_PATH를 적용하기 위해 ~/.bashrc 파일을 열고,

아래 export 2줄을 추가해줍니다. 설정 저장을 위해 파일 저장 후 source ~/.bashrc 명령을 실행해줍니다.

설정 후 java -version 명령으로 확인해보면 아래와 같이 JDK-17 버전이 설정된 것을 확인할 수 있습니다.

JDK-17 설치 확인

JDK 17 설치가 완료되었습니다 !

[AWS RDS] AWS 프리티어 RDS MariaDB 구성하기

코딩하는 너구리 — Wed, 6 Sep 2023 23:39:08 +0900

AWS RDS를 사용할 일이 간혹 있었지만 매번 생성할 때마다 진행 순서대로 요약된 글을 찾으며 시간 보내는게 아까워서 기록해두려고 한다.

AWS RDS 프리티어를 사용하는 이유?

- 토이프로젝트 혹은 개인 프로젝트를 진행하면서 DB 서버를 구성할 때, 수익화가 되지 않은 서비스를 유지하기 위해 서버비용을 지불하는것은 돈이 아깝다고 생각한다. 대부분의 개인 프로젝트의 경우 1년 이내에 서비스가 종료되기 때문에 무료에 가까운 비용으로 1,000명 이하가 사용하는 서비스의 DB 서버를 사용한다면 이보다 좋은 선택지는 없다고 생각한다.

최근 RDS를 이용해서 구성한 DB서버 유지비용은 월 약 3,000원 정도였다.
아직까지 이것보다 좋은 대안은 발견하지 못했다.

RDS	단일 AZ db.t2.micro	0	프리티어
RDS	DB 스토리지 20GB	0	프리티어
RDS	DB 백업용 스토리지 20GB	0	프리티어
기타	네트워크 통신 비용 등	2,000원	1년간 프리티어 적용

RDS 프리티어 지원내용

이제 차근차근 DB를 구성해보자. 2023년 9월 기준으로 AWS RDS를 생성하는 방법을 정리한 글입니다.

RDS 선택

데이터베이스 생성 버튼

MariaDB 선택

엔진은 MariaDB를 선택해줍니다.

MariaDB를 선택한 이유?

- 쿼리 문법이 동일하게 사용은 동일하지만 속도 및 성능, 안정성에서 더 최적화되었다고 합니다. AWS에 기재된 내용이니 자세한 내용은 아래 링크를 참고하길 바랍니다.
https://aws.amazon.com/ko/compare/the-difference-between-mariadb-vs-mysql/

MariaDB와 MySQL 비교 - 오픈 소스 관계형 데이터베이스 간의 차이점 - AWS

MySQL과 MariaDB는 모두 오픈 소스 데이터베이스 기술입니다. 이들 데이터베이스를 사용하여 행과 열이 있는 표 형식으로 데이터를 저장할 수 있습니다. MySQL은 가장 널리 채택된 오픈 소스 데이터

aws.amazon.com

MySQL vs MariaDB 비교

프리티어 설정

프리티어를 선택해줍니다. AWS 프리티어 서비스는 정말 최고의 서비스입니다.

DB 기본계정 정보 설정

인스턴스 선택

스토리지 설정

스토리지는 20GB까지는 무료이므로 20GB로 선택해줍니다. 기본 최대 스토리지 임계값이 1000으로 되어있지만, 불필요 과금을 막기위해 저는 100GB로 설정했습니다. 개인프로젝트의 경우 스토리지 자동조절 기능도 보통 꺼두지만 저는 서비스 유연성을 위해 켜두었습니다

연결 설정

EC2와 같이 사용한다면 'EC2 컴퓨팅 리소스에 연결'을 선택하시면 됩니다.
저는 RDS만을 구성하는 것이므로 연결 안함을 선택했습니다.

퍼블릭 액세스, 보안그룹 생성

퍼블릭 액세스는 '아니요'를 설정하면 내부에서만 DB 접근이 가능합니다. 저는 외부 API 서버에서 사용할 예정이므로 '예'를 선택했습니다. 다양한 DB 툴을 통해 접근하거나 개발시 IntelliJ에서 접근하려는 경우 '예'를 선택해야합니다.
+ 가용영역은 서울 리전을 사용하신다면 ap-northeast-2a 로 선택하면 됩니다.

데이터베이스 기본 설정

DB를 실행시킬, DB 접속에 사용할 포트를 선택합니다. 이전에 설정한 계정/암호로 접근할 것이기 때문에 암호 인증을 선택해줍니다.

데이터베이스 추가 구성 설정

DB 인스턴스 생성시 기본으로 생성할 database가 있다면 생성해줍니다.
그외 나머지 아래 값들은 기본으로 생성, 불필요한 모니터링 옵션들은 모두 비활성화 했습니다.

DB 인스턴스 생성 확인창

데이터베이스 생성 직전에 월별 추정 요금을 보고 식겁하시는 분들이 많이 계실거라고 보이는데요.
프리티어로 1년동안은 월 2,000 ~ 3,000원 정도의 요금으로 이용 가능하니 걱정하지 말고 데이터베이스를 생성하면 됩니다.

생성된 DB 인스턴스

이제 인스턴스 생성에는 성공했습니다.
추가적으로 보안그룹 설정 및 인코딩, DBMS 기준 서버시간 설정을 진행하도록 하겠습니다.
불필요한 설정은 하지 않아도 되지만 기본적으로 자주 설정하는 옵션들에 대한 설정 방법들입니다.

추가 설정 1) 보안그룹 설정

불필요한 외부 접근을 막기 위해 보안그룹을 설정해야 한다. 이는 사용자의 목적에 따라 다르지만 DB에 접근할 본인의 연결에 대한 정보만 허용하고 나머지는 허용하지 않도록 설정하면 된다.

보안그룹 수정을 위해 RDS 인스턴스를 클릭하고 보안 그룹을 선택하여 수정 화면으로 이동한다.

보안그룹 확인

인바운드 규칙 편집

보안그룹 선택 > 인바운드 규칙 > 인바운드 규칙 편집 클릭 후 접근 허용할 목록을 입력 후 저장해주면 된다.

추가 설정 2) 파라미터 그룹 설정

파라미터 그룹

파라미터 그룹 생성

RDS 인스턴스 생성시 선택한 타입과 버전을 선택합니다.

파라미터 그룹 편집

파라미터 그룹이 생성되면 [편집]을 클릭해서 설정을 추가하도록 하겠습니다.

timezone 설정

제일 먼저 timezone 설정입니다. Asia/Seoul로 설정했습니다.

인코딩 설정-1

인코딩 설정 - 2

두번째는 DB 인코딩 설정입니다. utf8mb4는 기본 문자, 한글 외에도 이모지와 같은 UTF-8 기준 모든 문자열 데이터를 저장할 수 있습니다. utf8mb4로 설정해주었습니다.

collation 수정 - 1

collation 수정 - 2

위와 같이 설정 후 저장한다.

저장한 다음에는 DB 인스턴스에 해당 파라미터 설정을 적용해주어야 한다.
아래와 같이 [수정] 버튼 클릭 후 설정한 파라미터 그룹과 인스턴스를 연결해준뒤 설정 적용을 위해 재부팅을 진행해주자.

이제 기본 구성은 끝났다 !

IntelliJ에서 Database를 연결해보자.

DB 접속

엔드포인트 확인

RDS 엔드포인트 및 포트정보를 확인해서 작성해주자.

연결 성공

연결에 성공했다. 이제 외부에서 RDS로 구성한 DB에 접근하여 사용하도록 하자.

점메추 사이트

코딩하는 너구리 — Mon, 3 Apr 2023 12:51:10 +0900

아래 이미지를 클릭하여 점메추 사이트에 접속이 가능합니다.

한식, 일식, 중식, 양식, 분식, 아시안, 디저트 다양한 점심 메뉴 추천 사이트입니다.

JAVA HttpClient와 CloseableHttpClient 차이점

코딩하는 너구리 — Fri, 3 Feb 2023 13:54:18 +0900

Java에서 HTTP API를 개발하기 위해 HttpClient를 자주 사용했었는데

CloseableHttpClient 클래스가 새롭게 등장했다고 해서 처음 알게되었다.

CloseableHttpClient 클래스는 Apache HttpClient 4.3 이상에서 새롭게 추가된 클래스로, HttpClient 클래스의 문제점을 개선하여 구현이 간편하고 메모리 누수 등의 문제가 해결되었다고 한다.

따라서, 새로운 프로젝트에서는 CloseableHttpClient 클래스를 사용하는 것이 권고되고 있는데, 기존의 HttpClient 클래스와의 차이점을 정리해보면 다음과 같다.

생성 방식

DefaultHttpClient: HttpClient 인스턴스를 생성하는 것이 가능한 방법 중 가장 기본적인 방식입니다.
CloseableHttpClient: DefaultHttpClient의 기능을 확장하여 HttpClient 인스턴스의 생성을 지원하며, 각 Connection의 자원을 안정적으로 관리할 수 있는 메소드를 제공합니다.

close 메소드 사용 여부

DefaultHttpClient: close 메소드를 제공하지 않습니다.
CloseableHttpClient: close 메소드를 제공하여 HttpClient 인스턴스의 연결을 닫을 수 있습니다.

예제

CloseableHttpClient httpClient = HttpClients.createDefault();
try {
  HttpGet httpGet = new HttpGet("<http://www.google.com>");
  CloseableHttpResponse response = httpClient.execute(httpGet);
  // Do something with response
} finally {
  httpClient.close();
}

HTTP 통신 가능 회수

DefaultHttpClient: HTTP 통신을 계속 할 수 있습니다.
CloseableHttpClient: 각 Connection을 제대로 닫지 않으면 일정 횟수 이상 HTTP 통신이 불가능 할 수 있습니다.

Connection Pool 사용 여부

DefaultHttpClient와 CloseableHttpClient 모두 Connection Pool 기능을 제공

[프로그래머스] 배열 두 배 만들기 JAVA

코딩하는 너구리 — Fri, 14 Oct 2022 16:42:31 +0900

배열 두 배 만들기

문제 설명

정수배열 numbers가 매개변수로 주어집니다. numbers의 각 원소에 두배한 원소를 가진 배열을 return하도록 solution 함수를 완성해주세요.

제한 사항

-10,000 ≤ numbers의 원소 ≤ 10,000
1 ≤ numbers의 길이 ≤ 1,000

입출력 예

numbers	result
[1, 2, 3, 4, 5]	[2, 4, 6, 8, 10]
[1, 2, 100, -99, 1, 2, 3]	[2, 4, 200, -198, 2, 4, 6]

입출력 예 설명

입출력 예 #1

[1, 2, 3, 4, 5]의 각 원소에 두배를 한 배열 [2, 4, 6, 8, 10]을 return합니다.

입출력 예 #2

[1, 2, 100, -99, 1, 2, 3]의 각 원소에 두배를 한 배열 [2, 4, 200, -198, 2, 4, 6]을 return합니다.

문제 접근 방식

for 반복문을 사용해 풀이하면 된다고 생각했습니다.

class Solution {
    public int[] solution(int[] numbers) {
        for(int i = 0; i < numbers.length; i++) {
            numbers[i] *= 2;
        }
        return numbers;
    }
}

문제 풀이

for 반복문을 주어진 numbers 배열의 길이만큼 반복하며 각 요소에 2를 곱한 결과를 저장해주었습니다.

고수의 풀이

저는 for 반복문을 사용했지만, java 8 문법인 Stream을 사용하면 더 간결한 코드로 정답을 찾을 수 있었습니다.

stream의 map 메소드에서 각 요소인 i에 i*2해준 값들을 Array로 만들어 return 해주었습니다.

import java.util.Arrays;

class Solution {
    public int[] solution(int[] numbers) {
        return Arrays.stream(numbers).map(i -> i * 2).toArray();
    }
}

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120807

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

[프로그래머스] 숫자 비교하기 JAVA

코딩하는 너구리 — Thu, 13 Oct 2022 23:49:28 +0900

숫자 비교하기

문제 설명

정수 num1과 num2가 매개변수로 주어집니다. 두 수가 같으면 1 다르면 -1을 return 하도록 solution 함수를 완성해주세요.

제한 사항

0 ≤ num1 ≤ 10,000
0 ≤ num2 ≤ 10,000

입출력 예

num1	num2	result
2	3	-1
11	11	1
7	99	-1

입출력 예 설명

입출력 예 #1

num1이 10, num2가 5이므로 10을 5로 나눈 몫 2를 return 합니다.

입출력 예 #2

num1이 7, num2가 2이므로 7을 2로 나눈 몫 3을 return 합니다.

문제 접근 방식

JAVA 덧셈 연산을 이용하면 풀이할 수 있다고 생각했습니다.

class Solution {
    public int solution(int num1, int num2) {
        return num1 == num2 ? 1 : -1;
    }
}

문제 풀이

삼항 연산자를 이용해 같을 경우(==) 1을 return하고

같지 않을 경우(다른 경우)에 -1을 return 하도록 해주었습니다.

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120807

프로그래머스

programmers.co.kr

[자료구조] Java ArrayList 알아보기

코딩하는 너구리 — Wed, 12 Oct 2022 23:57:15 +0900

2022.10.08 - [IT/자료구조] - [자료구조] 배열(Array)의 개념

[자료구조] 배열(Array)의 개념

오늘은 자료구조에서 가장 기본으로 다루는 배열에 대해 정리해보겠습니다. 배열이란? 같은 타입의 변수들로 이루어진 유한 집합 배열은 같은 종류의 데이터를 다뤄야 하는 경우에 사용할 수

javacoding.tistory.com

ArrayList 개념

ArrayList 사용 예시

지난번 배열에 이어 두 번째 자료구조로 Array와 비슷한 ArrayList에 대해 알아보겠습니다.

배열의 가장 큰 특징 중 하나는 크기가 고정된다는 것입니다. 배열을 생성할 때 사용할 크기를 알고 있다면 배열을 사용하는 것이 속도나 메모리 사용의 측면에서 이점이 되겠지만 사용할 배열의 크기를 알지 못하거나 수정이 필요한 경우에는 가변적인 배열이 필요하게 됩니다.

이럴때 적합한 자료구조가 바로 ArrayList입니다. 가장 큰 특징은 크기가 가변적이라는 것인데요.

위 그림처럼 배열로 사용하다가 공간이 가득차게 되면, 크기를 증가시켜줍니다.

따라서

ArrayList를 가장 잘 표현할 수 있는 단어는
dynamic array 또는 resizable array 라고 할 수 있습니다.

ArrayList 구현

ArrayList 상속 구조

ArrayList는 Java Collection 프레임워크의 클래스입니다.

ArrayList 특징

배열과 유사하지만 크기 제한이 없습니다. (가변적)
중복 요소를 저장할 수 있습니다.
기본적으로 삽입한 순서가 보장됩니다. (index 지정 추가/삭제한 경우 제외)
Collection 인스턴스입니다.
래퍼 클래스로만 사용 가능합니다. (기본 클래스(ex - int, char...)는 사용 불가능)

참조:

https://www.javatpoint.com/arraylist-implementation-in-java

https://marcus-biel.com/arraylist

https://kjhoon0330.tistory.com/m/entry/Java-ArrayList%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%81%AC%EA%B8%B0%EA%B0%80-%EA%B0%80%EB%B3%80%EC%A0%81%EC%9D%BC%EA%B9%8C

용인 역북 솥뚜껑 삽겹살 읏듬 (고기 존맛)

코딩하는 너구리 — Mon, 10 Oct 2022 20:17:51 +0900

용인 역북동 주민 n년차의 추천글
: 스타벅스 위에 고기집이 새로 생겨 방문해보았습니다 (미리말하자면 성공적)
통유리로 되어있어 멀리서봐도 잘보이더라구요!

읏듬의 메뉴판입니다 ~~

진짜 솥뚜껑이에요 ㅋㅋ

요집의 특이점은 전통주를 판다는 것!
전통주의 가격은 메뉴판에 나와있지 않아 아쉬웠지만
주종이 다양해서 한번쯤 도전해볼만 한거같습니다ㅋ

반찬은 다양해서 좋았어요 (맛도 있음)
고기는 셀프로 굽는 방식이고
다 구워갈때쯤 김치, 고사리, 콩나물을
같이 구워드시라고 말씀해주셨습니다!

전체적으로 상이 넓어서 자리가 널널한게
너어어무 좋았어요 ㅋㅋ

폭탄계란찜(4.0)
누구나 다 아는 그 계란찜 맛ㅋㅋ

이렇게 가격표를 같이 붙여서 주시더라구요!
저희는 처음에
읏듬 삽겹살(15.0)
읏듬 특전지(10.0)
시켰구요 다먹고 특전지 하나 더시켰습니다
(특전지 저렴해서 기대안했는데 존맛임)

솥뚜껑이라 그런지 아주 빨리
맛있게 잘 익어주었습니다 ㅎㅎ

고기 질은 좋은거 같아요!
특히 전지 진짜 부들부들
씹는거 안좋아하는 사람은 무조건 시키세요 (저에요)

소주 2000원 행사해서 2병 조져주었어요
2병먹고 4000원 개꿀

볶음밥 하나 더 시켜서 마무리했습니다
고기랑 볶음밥 꼭 같이드세요
죤맛이니까……

정보가 없어 소신껏 작성해본 글입니다 ㅋㅋ
물론 광고 네버X이구요
역북동에서 맛있는거 같이 먹어요
(계산하고 나와서 10분만에 쓰는 글입니다ㅋㅋ)

[프로그래머스] 나머지 구하기 JAVA

코딩하는 너구리 — Mon, 10 Oct 2022 10:27:11 +0900

나머지 구하기

문제 설명

정수 num1, num2가 매개변수로 주어질 때, num1을 num2로 나눈 나머지를 return 하도록 solution 함수를 완성해주세요

제한 사항

0 < num1 ≤ 100
0 < num2 ≤ 100

입출력 예

num1	num2	result
3	2	1
10	5	0

입출력 예 설명

입출력 예 #1

num1이 3, num2가 2이므로 3을 2로 나눈 나머지 1을 return 합니다.

입출력 예 #2

num1이 10, num2가 5이므로 10을 5로 나눈 나머지 0을 return 합니다.

문제 접근 방식

JAVA 나머지 연산을 이용하면 풀이할 수 있다고 생각했습니다.

class Solution {
    public int solution(int num1, int num2) {
        return num1 % num2;
    }
}

문제 풀이

num1과 num2가 입력으로 주어지므로 바로 나머지 연산 결과를 return 했습니다.

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120810

프로그래머스

programmers.co.kr

[프로그래머스] 몫 구하기 JAVA

코딩하는 너구리 — Sun, 9 Oct 2022 01:19:03 +0900

몫 구하기

문제 설명

정수 num1과 num2가 매개변수로 주어질 때, num1을 num2로 나눈 몫을 return 하도록 solution 함수를 완성해주세요

제한 사항

0 < num1 ≤ 100
0 < num2 ≤ 100

입출력 예

num1	num2	result
10	5	2
7	2	3

입출력 예 설명

입출력 예 #1

num1이 10, num2가 5이므로 10을 5로 나눈 몫 2를 return 합니다.

입출력 예 #2

num1이 7, num2가 2이므로 7을 2로 나눈 몫 3을 return 합니다.

문제 접근 방식

JAVA 덧셈 연산을 이용하면 풀이할 수 있다고 생각했습니다.

class Solution {
    public int solution(int num1, int num2) {
        return num1 / num2;
    }
}

문제 풀이

num1과 num2가 입력으로 주어지므로 바로 나눗셈 결과를 return 했습니다.

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120805

프로그래머스

programmers.co.kr

[프로그래머스] 두 수의 곱 JAVA

코딩하는 너구리 — Sun, 9 Oct 2022 01:15:23 +0900

두 수의 곱

문제 설명

정수 num1, num2가 매개변수로 주어집니다. num1과 num2를 곱한 값을 return 하도록 solution 함수를 완성해주세요.

제한 사항

0 ≤ num1 ≤ 100
0 ≤ num2 ≤ 100

입출력 예

num1	num2	result
3	4	12
27	19	513

입출력 예 설명

입출력 예 #1

num1이 3, num2가 4이므로 3 * 4 = 12를 return합니다.

입출력 예 #2

num1이 27, num2가 19이므로 27 * 19 = 513을 return합니다.

문제 접근 방식

JAVA 곱셈 연산을 이용하면 풀이할 수 있다고 생각했습니다.

class Solution {
    public int solution(int num1, int num2) {
        return num1 * num2;
    }
}

문제 풀이

num1과 num2가 입력으로 주어지므로 바로 곱셈 결과를 return 했습니다.

최종 코드

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120804

프로그래머스

programmers.co.kr

[프로그래머스] 두 수의 차 JAVA

코딩하는 너구리 — Sun, 9 Oct 2022 01:10:36 +0900

두 수의 차

문제 설명

정수 num1과 num2가 주어질 때, num1에서 num2를 뺀 값을 return 하도록 solution 함수를 완성해주세요.

제한 사항

-50000 ≤ num1 ≤ 50000
-50000 ≤ num2 ≤ 50000

입출력 예

num1	num2	result
2	3	-1
100	2	98

입출력 예 설명

입출력 예 #1

num1이 2이고 num2가 3이므로 2 - 3 = -1을 return합니다.

입출력 예 #2

num1이 100이고 num2가 2이므로 100 - 2 = 98을 return합니다.

문제 접근 방식

JAVA 뺄셈 연산을 이용하면 풀이할 수 있다고 생각했습니다.

class Solution {
    public int solution(int num1, int num2) {
        return num1 - num2;
    }
}

문제 풀이

num1과 num2가 입력으로 주어지므로 바로 뺄셈 결과를 return 했습니다.

최종 코드

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120803

프로그래머스

programmers.co.kr

[프로그래머스] 두 수의 합 JAVA

코딩하는 너구리 — Sun, 9 Oct 2022 01:03:40 +0900

두 수의 합

문제 설명

정수 num1과 num2가 주어질 때, num1과 num2의 합을 return 하도록 solution 함수를 완성해주세요.

제한 사항

-50,000 ≤ num1 ≤ 50,000
-50,000 ≤ num2 ≤ 50,000

입출력 예

num1	num2	result
2	3	5
100	2	102

입출력 예 설명

입출력 예 #1

num1이 2이고 num2가 3이므로 2 + 3 = 5를 return합니다.

입출력 예 #2

num1이 100이고 num2가 2이므로 100 + 2 = 102를 return합니다.

문제 접근 방식

JAVA 덧셈 연산을 이용하면 풀이할 수 있다고 생각했습니다.

class Solution {
    public int solution(int num1, int num2) {
        return num1 + num2;
    }
}

문제 풀이

num1과 num2가 입력으로 주어지므로 바로 덧셈 결과를 return 했습니다.

최종 코드

출처 : https://school.programmers.co.kr/learn/courses/30/lessons/120802

프로그래머스

programmers.co.kr

[자료구조] 배열(Array)의 개념

코딩하는 너구리 — Sat, 8 Oct 2022 23:59:09 +0900

오늘은 자료구조에서 가장 기본으로 다루는 배열에 대해 정리해보겠습니다.

배열이란?

같은 타입의 변수들로 이루어진 유한 집합

배열의 구조

배열은 같은 종류의 데이터를 다뤄야 하는 경우에 사용할 수 있는 가장 기본적인 자료구조 입니다.

중요한 건 int 데이터를 모으는 int 배열, String 데이터를 모으는 String 배열처럼 같은 자료형 데이터들만 담을 수 있습니다.

배열을 구성하는 각각의 배열 요소를 element라고 하며, 배열에서의 위치를 가리키는 숫자를 index라고 합니다. 자바에서 인덱스는 언제나 0부터 시작하며, 0을 포함한 양의 정수만을 가질 수 있습니다.

배열은 선언되는 형식에 따라 1차원 배열, 2차원 배열, 3차원 배열 등 다차원 배열로 선언이 가능하지만 현실적으로 이해하기 쉬운 2차원 배열까지가 주로 사용됩니다.

주요 특징 및 장단점

Java의 모든 배열은 동적으로 할당됩니다.

동적 할당 : 실행 시간(Runtime) 동안 사용할 공간을 힙(heap) 메모리에 할당하는 것을 말합니다.

배열의 크기는 정수값으로만 지정할 수 있습니다.

배열의 변수는 순서가 지정되며 0부터 시작하는 인덱스를 가집니다.

배열에 n개의 데이터가 존재할 때 인덱스 번호는 [0 ~ n-1]으로 순차적임.
인덱스도 정수값임.

배열의 크기는 초기화되면 변경할 수 없습니다.

배열의 크기를 실시간으로 변경할 수 없지만 다른 배열을 가리키도록 만들 순 있음.
다른 크기의 배열을 사용하기 위해서는 새 배열을 만들어 할당해야 함.

다차원 배열 구현이 가능합니다. (보통 2차원 이상은 잘 사용하지 않음)

가장 큰 특징은 순차적으로 데이터를 저장한다는 것입니다.

index를 사용해 특정 요소에 바로 접근이 가능한 것이 배열의 주요 장점입니다.

순차적으로 존재하는 데이터 중간 요소를 삽입 또는 삭제하는 경우에는 요소 뒤쪽의 데이터들을 모두 한 칸씩 옮겨주어야 하기 때문에 상대적으로 번거롭습니다.
-> 잦은 추가, 삭제시 배열 사용은 부적합 합니다.

따라서 배열은 주식차트와 같이 순서가 주요한 경우에 적합한 자료구조 입니다.

생성과 초기화

: 배열 선언은 컴퓨터에게 해당 크기만큼 메모리를 잡아놓도록 하는 것이고

초기화란 잡아놓은 메모리에 값을 채워넣는 것을 말합니다.

배열 선언

1차원 배열은 주로 다음 두 가지 문법에 따라 선언합니다.

// 1. type[] name;
int[] array;

// 2. type name[];
int array[];

일반적으로 1번의 방법을 사용합니다. 앞으로 예시에서는 모두 1번 방식을 사용하도록 하겠습니다.

타입은 배열 요소로 저장되는 변수의 자료형을 나타냅니다.
배열 이름은 배열이 선언된 후 배열에 접근하기 위해 사용됩니다.

배열의 생성

// 타입[] 배열이름 = new 타입[배열 길이];
int[] array = new int[10];

String[] dayOfWeek = new String[7];

첫 번째 배열 array는 int 자료형 10개를 담을 수 있는 배열입니다.

두 번째 배열 dayOfWeek는 String 자료형 7개를 담을 수 있는 배열입니다.

배열의 초기화

: 배열 초기화는 필요한 시기에 따라 다양한 방식으로 이루어질 수 있습니다. 3가지 경우를 간단한 예시와 함께 살펴보겠습니다.

1) 배열 선언과 동시에 초기화

int[] array = {10, 20, 30};

int[] array2 = new int[]{3, 6, 9};

2) 배열 선언 후 생성과 함께 초기화

int[] array;
array = new int[]{1,2,3};

3) 인덱스를 이용한 접근 후 초기화

int[] array = new int[3];

for(int i = 0; i< 3; i++) {
    array[i] = i+1;
}

// array[0] = 1
// array[1] = 2
// array[2] = 3

for 반복문과 배열

: 배열에 값을 초기화하거나 요소 접근 및 특정 요소 검색을 위해서 반복문과 함께 사용되는 경우가 많습니다.

간단하게 배열에 요일값을 초기화하고 원하는 요일을 검색하는 예시를 확인해보겠습니다.

String[] weeks = {"월요일", "화요일", "수요일", "목요일", "금요일", "토요일", "일요일"};

// 토요일 찾기
for(int i = 0; i< 7; i++) {
    if(weeks[i].equals("토요일")) {
        System.out.println("토요일은 " + (i+1) +"번째!");
    }
}

// 출력: "토요일은 6번째!"

Array와 ArrayList 비교

주요 차이점은 다음과 같습니다.

배열(Array)은 크기가 고정적인데 반해 ArrayList는 크기가 가변적입니다.
배열(Array)는 초기화 시 메모리에 할당되어 속도가 빠르지만, ArrayList는 데이터 추가 및 삭제시 메모리 재할당이 필요하여 배열에 비해 속도가 느립니다.

Array와 LinkedList 비교

Array는 인덱스로 해당 원소에 접근할 수 있어 찾고자 하는 원소의 인덱스를 알고 있다면 O(1)로 접근 가능
삭제시에는 이후 배열 요소들을 옮겨줘야 하기 때문에 O(n)의 시간복잡도를 가짐

LinkedList는 각각의 요소들은 자기 자신 다음에 어떤 요소인지만 기억하고 있기 때문에 이 부분을 다른 값으로 바꿔주면 O(1) 비용으로 삽입과 삭제가 가능함
원하는 위치에 한 번만 접근할 수 없다는 단점이 있음. 원하는 위치를 Search하는 과정에 있어서 첫번째 원소부터 다시 확인해봐야 함.

Array -> 검색이 빠르지만 삽입, 삭제는 느림

LinkedList -> 삽입 삭제가 빠르지만 검색이 느림

참고

https://www.softwaretestinghelp.com/c-sharp/csharp-arrays/

http://tcpschool.com/java/java_array_oneDimensional

https://dev-coco.tistory.com/159?category=1056309

[Network] TCP Packet(Segment) 분석

코딩하는 너구리 — Fri, 7 Oct 2022 15:06:56 +0900

https://javacoding.tistory.com/167

[Network] TCP 3 Way Handshaking & 4 Way Handshaking

https://javacoding.tistory.com/162 TCP란? https://javacoding.tistory.com/160 IP(Internet Protocol) 내가 인터넷을 통해 정보를 원하는 곳으로 전달하고자 할 경우, 도착지를 알아야 한다. 나의 주소와 상대..

javacoding.tistory.com

이전 글에서 3-way handshake와 4-way handshake에 대해 정리했습니다.

서버와 클라이언트 간 확인을 위해 SYN과 ACK를 주고 받았는데요. 이 정보들은 패킷(Packet)에 담아 전송됩니다.

그렇다면 TCP 전송에 이용되는 Packet은 어떤 구조를 갖고 있을까요? 이번 글에서는 TCP 헤더 구조에 대해 알아보도록 하겠습니다.

Packet이라는 용어?
이 글에서는 TCP 통신에 전달되는 데이터를 Packet으로 불렀습니다.
하지만 프로토콜에서 전달되는 데이터는 프로토콜 계층(Layers)마다 부르는 이름이 조금씩 다릅니다.

전달되는 payload(데이터)는 같지만 앞에 어떤 헤더 정보가 포함되어 있냐에 따라
Physical Layer에서는 Bit를 단위로 하고,
Data Link Layer에서는 Frame이라 하고,
Network Layer에서는 Packet이라 하고,
Transport Layer에서는 Segment라고 합니다.

따라서 오늘 정리해보려고 했던 TCP 데이터 구조는
발신지 포트, 목적지 포트, 시퀀스 번호 등을 포함하는 세그먼트(Segment)라고 부르는 것이 더 정확합니다. 지금부터는 Packet이 아닌 TCP Segment로 기재하도록 하겠습니다.

TCP Segment 구조

TCP 헤더 구조

Source port, Destination port

Source port : 송신하는 application 포트
Destination port : 수신해야 할 application 포트

출발지와 목적지의 포트 번호 정보를 담는 필드입니다.

주소는 IP 주소와 포트 번호를 사용해서 나타낼 수 있는데, IP 정보는 IP 헤더에 담겨있고 TCP 헤더에는 포트 번호를 나타내는 필드가 존재합니다.

Sequence Number

Sequence number : TCP 세그먼트의 연속된 데이터 번호입니다.

시퀀스 번호 덕분에 수신 측에서 쪼개진 세그먼트의 순서를 올바르게 재조립할 수 있습니다.

송신측에서 데이터를 전송할 때는 난수를 생성하며 이후 자신이 보낼 데이터 1 bytes당 시퀀스 번호를 1씩 증가시키며 데이터 순서를 표현합니다.

Acknowledgment number

Acknowledgment number : 상대방으로부터 받아야 하는 다음 TCP 세그먼트 데이터 번호입니다.

ACK number는 연결을 맺거나 해제할 때 3-way, 4-way handshake 과정에서는 상대방이 보낸 시퀀스 번호에 +1을 자신의 ACK number를 만들어내지만, 실제 데이터를 주고 받을 때에는 상대방이 보낸 시퀀스 번호 + 자신이 받은 데이터의 bytes로 ACK number를 만들어 냅니다.

즉, 해당 번호 앞까지 데이터 처리가 완료되어 해당 번호 TCP 세그먼트를 전송해달라는 의미입니다.

TCP Segment 구조에서 알아보려 했던 Sequence number, ACK number를 제외한 나머지 구조에 대해서는 간략히 정의에 대해서만 정리하도록 하겠습니다.

Data Offset : 전체 세그먼트 중에서 헤더가 아닌 데이터가 시작되는 위치가 어디인지를 나타냅니다.
Reversed : 미래를 위해 예약된 필드로, 모두 0으로 채워져야 한다.
Flags : 현재 세그먼트의 속성을 나타내는 9개의 비트 플래그입니다.
Window Size : 한번에 전송할 수 있는 데이터의 양을 의미합니다.
Checksum : 데이터를 송신하는 중에 발생할 수 있는 오류를 검출하기 위한 값입니다.
Urgent Pointer : 긴급 포인터입니다. URG 플래그 값이 1이면 수신 측은 이 포인터가 가리키고 있는 데이터를 우선적으로 처리합니다.
Options : TCP의 기능을 확장할 때 사용하는 필드들입니다.

TCP의 특징에 대해서 정리해보면서 TCP Segment 구조에 대해서 공부해보게 되었는데, 공부할수록 부족한 부분들이 많이 보이는 것 같다. 조금씩 시간을 내서 네트워크에 대해 공부하는 시간을 갖도록 노력해야겠다.

참고 : https://evan-moon.github.io/2019/11/10/header-of-tcp/

[Network] TCP 3 Way Handshaking & 4 Way Handshaking

코딩하는 너구리 — Thu, 6 Oct 2022 23:47:18 +0900

https://javacoding.tistory.com/162

TCP란?

https://javacoding.tistory.com/160 IP(Internet Protocol) 내가 인터넷을 통해 정보를 원하는 곳으로 전달하고자 할 경우, 도착지를 알아야 한다. 나의 주소와 상대의 주소는 어떻게 나타낼 수 있을까? 이때 PC..

javacoding.tistory.com

이전에 TCP 프로토콜에 대해 정리하면서 확인한 TCP의 가장 뚜렷한 특징중 하나는 신뢰성이었습니다.
TCP에서는 어떻게 송, 수신시에 신뢰성을 보장할 수 있을까요?

TCP에서는 데이터를 보낼 때 송신자와 수신자간 연결을 확인한 뒤 데이터를 전송하고,
연결을 해제할 때에는 연결을 해제해도 되는지 서로 확인 후에 해제합니다.

연결 시 확인하는 과정이 3-Way-HandShaking이고,
연결 해제 시 확인하는 과정이 4-Way-HandShaking 입니다.

3-Way-HandShaking

응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미합니다.

데이터 전송 전에 상대방이 수신할 준비되었는지 확인할 수 있습니다.

패킷에 담긴 정보를 확인해서 HandShaking 과정이 이루어지는데 다음 두 가지 정보가 주요 역할을 하니 알아 두도록 합시다.

SYN(sequence number) : 난수값, 이 값은 나중에 데이터를 주고 받을 때 기준이 되는 값으로 사용됨.
* 난수값을 사용하는 이유?
두 호스트가 연결을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용 됨. 따라서 두 호스트는 과거에 사용된 포트번호 쌍을 사용할 가능성이 존재함. 그렇기 때문에 만약 난수가 아닌 연속된 숫자를 사용할 경우에 이전 연결에서 오는 패킷인지 구분이 안될 수 있기 때문에 난수로 사용함.

ACK(acknowledgement) : 송신자가 보낸 SYN에 +1을 한 값. 송신자가 100을 보내고 수신자가 101을 보내면 서로의 존재를 인지하고 있다고 생각하면 됨.

3-way-handshaking 과정

STEP 1 - 클라이언트가 서버에게 접속을 요청하는 SYN 패킷을 보냅니다.
STEP 2 - 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK와 SYN을 보냅니다.
STEP 3 - 클라이언트가 서버에게 ACK를 보냅니다.

위의 과정을 통해서 서버와 클라이언트는 서로 연결되었음을 확인했습니다. 이후 데이터를 주고받게 됩니다. 상대방이 데이터를 받을 준비가 되었다는 것을 확인했으니 데이터를 제대로 보냈다고 생각할 수 있겠죠? 신뢰성이 느껴집니다.

4-Way-HandShaking

응용프로그램이 상대방 컴퓨터와 세션을 해제하는 과정을 의미합니다.

연결 해제시 상대방이 더이상 보낼 데이터가 없는지 확인할 수 있습니다.

4-way-handshaking 과정

STEP 1 - 클라이언트가 서버에게 종료하겠다는 FIN을 보냅니다.
STEP 2 - 서버는 FIN을 받고 ACK를 보낸 후 자신이 데이터를 모두 보낼때까지 기다립니다.
STEP 3 - 서버가 데이터를 모두 보냈다면 FIN을 클라이언트에게 보냅니다.
STEP 4 - 클라이언트는 ACK를 보내 응답하고 서버는 ACK를 수신하면 연결을 해제합니다.

STEP 2 과정에서 자신의 데이터를 모두 보낼때까지 대기하는데, 바로 연결을 해제하면 전송중이던 데이터가 유실될 수 있기 때문에 이를 방지하기 위함입니다.

TCP의 3-way-handshaking과 4-way-handshaking에 대해 정리해보았습니다.

다음번 글에서는 주고받는 Packet에 대해 조금 더 상세히 알아보면 좋지 않을까 싶습니다.

참고
- https://kosaf04pyh.tistory.com/162

[DB] 데이터베이스 트랜잭션의 4가지 특징(ACID)

코딩하는 너구리 — Thu, 6 Oct 2022 00:23:29 +0900

서버 개발자로서 DBMS를 사용할 때 가장 중요한 관심사 중의 하나는 데이터의 정합성 유지가 아닐까 생각합니다. DBMS가 일관된 결과를 생성하고 정합성을 유지하기 위해 트랜잭션을 이용해 작업을 처리하곤 합니다.

이번 글에서는 데이터베이스 트랜잭션의 개념과 4가지의 특성에 대해 알아보도록 하겠습니다.

트랜잭션

트랜잭션은 데이터베이스의 내용을 접근하고 수정하는 논리적 작업 단위입니다.

트랜잭션은 논리적인 작업들을 모두 완벽하게 처리하거나, 처리하지 못했을 경우에는 진행된 모든 작업들을 Rollback하고 원상태로 복구하여 작업의 일부만 적용되는 상황이 발생하지 않도록 하는 기능입니다.

데이터베이스의 일관성을 유지하기 위해 트랜잭션 전후에 특정 속성을 따르는데, 이를 ACID 속성이라고 합니다.

ACID 속성

ACID 속성은 원자성, 일관성, 독립성, 지속성을 나타내는데 하나씩 살펴보도록 하겠습니다.

원자성 (Atomicity)

원자성은 트랜잭션을 구성하는 작업들이 모두 정상적으로 실행되거나 전혀 실행되지 않음을 의미합니다.
트랜잭션이 부분적으로 발생하지 않습니다. 즉 중간은 없습니다.
원자성은 "All or nothing rule" 이라고도 알려져 있습니다.

각각의 특성을 설명할 때 이해를 돕기 위해 하나의 예시를 들어 확인해보겠습니다.

X의 계좌에서 Y의 계좌로 100원을 이체하는 과정입니다.

트랜잭션 예시

- Transaction T는 T1 작업(100원 송금)과 T2 작업(100원 입금)으로 구성되어 있습니다.

이때 트랜잭션 T1 작업이 완료되고 T2 작업이 완료되기 전에 실패하면

X의 계좌에서는 100원이 송금되고 Y의 계좌에는 100원이 입금되지 않은 상태여야 하지만 트랜잭션을 사용한다면

Transaction T의 작업이 롤백되어 모두 실행되지 않습니다.

일관성 (Consistency)

일관성은 데이터베이스의 정확성을 나타냅니다.
트랜잭션 전후에 항상 무결성 제약 조건을 유지함을 의미합니다.

위의 예시에서는

TransactionT가 발생하기 이전의 상태는 X계좌에 500원이 있고 Y 계좌에 200원이 있어 총 700원이 존재했습니다.

TransactionT 작업이 진행된 이후에도 거래 전후의 총액을 유지해야 합니다.

트랜잭션이 성공해서 X계좌에 400원, Y계좌에 300원이 존재하거나, 트랜잭션이 실패해서 X계좌에 500원, Y계좌에 200원인 상태로 일관된 총액 700원을 유지해야 합니다.

독립성 (Isolation)

독립성은 트랜잭션간에 간섭 없이 서로 독립적으로 수행됨을 의미합니다.
트랜잭션 수행 중 다른 트랜잭션 작업이 끼어들지 못하도록 보장하는 것을 말합니다.

트랜잭션간에 간섭이 일어나면 데이터 정합성 및 일관성 등 여러 문제가 발생할 수 있습니다.

지속성 (Durability)

지속성은 트랜잭션 실행이 완료되면 데이터베이스에 대한 업데이트 및 수정 사항이 영구적으로 반영됨을 의미합니다.
시스템 오류가 발생하더라도 해당 기록은 영구적이어야 합니다.

이렇게 RDBMS에서 트랜잭션의 4가지 속성인 원자성, 일관성, 독립성, 지속성에 대해 살펴보았습니다.

그냥 글을 마치기에는 조금 아쉬워서 DBMS 트랜잭션 상태에 대해서도 조금 더 찾아보았습니다.

아래 그림은 트랜잭션이 동작하는 동안 진행되는 상태를 나타냅니다.

Transaction 상태

활성 상태(Active State) : 트랜잭션 명령이 실행중일 때 트랜잭션은 활성 상태에 있습니다. 모든 읽기 및 쓰기 작업이 오류 없이 수행되면 부분적 커밋 상태가 됩니다. 만약 명령이 실패하면 실패 상태가 됩니다.

부분적 커밋 상태(Partially Committed State) : 모든 읽기 및 쓰기 작업이 완료된 후 변경사항이 데이터베이스에 영구적으로 적용되면 커밋된 상태로 변경되고 실패할 경우 실패 상태가 됩니다.

실패 상태(Failed State) : 트랜잭션 명령이 실패하면 실패 상태가 되거나 데이터베이스의 데이터를 영구적으로 변경하는 데 실패한 경우 실패 상태가 됩니다.

중단 상태(Abort State) : 오류가 발생한 후 트랜잭션은 실패 상태에서 중단 상태로 바뀌고 변경 사항이 삭제되거나 롤백됩니다.

커밋 상태(Committed State) : 데이터베이스에서 변경 사항이 영구적으로 반영된 상태입니다. 이후 종료 상태에서 종료됩니다.

종료 상태(Terminated State) : 트랜잭션이 종료되는 상태입니다.

이렇게 해서 트랜잭션의 ACID 특징과 트랜잭션 상태에 대해 알아보았습니다.

참고 : https://www.geeksforgeeks.org

[DB] 데이터베이스 제약조건과 PK, FK

코딩하는 너구리 — Wed, 5 Oct 2022 18:26:45 +0900

개발하면서 다양한 RDB를 사용하게 되는데, 이번 글에서는 데이터베이스 제약조건과 함께 PK, FK 특징에 대해 정리해볼까 합니다.

먼저 Constraint란 뜻에 대해 찾아보았는데요.

제약의 뜻을 가지고 있었습니다.

그렇다면 데이터베이스에서 말하는 제약조건이란 무엇일까요?

제약조건

제약 조건(constraint)이란 데이터의 무결성을 지키기 위해, 데이터를 입력받을 때 실행되는 검사 규칙을 의미합니다.
이러한 제약 조건은 CREATE 문으로 테이블을 생성할 때나 ALTER 문으로 필드를 추가할 때도 설정할 수도 있습니다.

제약조건에는 어떤 종류가 있을까요? MySQL에서 사용할 수 있는 제약 조건은 다음과 같습니다.

NOT NULL
UNIQUE
PRIMARY KEY
FOREIGN KEY
DEFAULT

NOT NULL부터 제약조건들을 하나씩 살펴보도록 하겠습니다.

NOT NULL

NOT NULL 제약 조건을 설정하면, 해당 필드는 NULL 값을 저장할 수 없습니다.
즉, 이 제약 조건이 설정된 필드는 무조건 데이터를 가지고 있어야 합니다.
NOT NULL 제약 조건은 CREATE 문으로 테이블을 생성할 때나, 나중에 ALTER 문으로 추가할 수도 있습니다.

CREATE 시 NOT NULL 설정

: CREATE 문으로 테이블을 생성할 때 해당 필드의 타입 뒤에 NOT NULL을 명시하면, 해당 필드는 NULL 값을 가질 수 없습니다.

CREATE TABLE Test
(
    ID INT NOT NULL,
    Name VARCHAR(30),
    ReserveDate DATE,
    RoomNum INT
);

위 쿼리처럼 ID 필드에 NOT NULL 제약조건을 설정하고 테이블을 생성한 뒤 테이블의 상세 정보를 확인하면 다음과 같습니다.

NOTNULL 적용 예시

이제부터 Test 테이블에서 INSERT 문으로 새로운 레코드를 추가할 때 ID 필드의 값으로 NULL을 사용할 수 없습니다.

NOT NULL 제약조건이란 해당 필드에 NULL 값을 저장할 수 없도록 설정하는 것으로, 해당 필드를 생략하지 못하도록 하는 제약조건은 아님을 기억해두길 바랍니다.

실제로 ID 필드가 생략된 경우에도 레코드 저장이 가능한데, SQL예시와 생성 결과는 아래와 같습니다.

INSERT INTO Test (Name, ReserveDate, RoomNum)
VALUES('이순신', '2016-02-16', 1108);

NOTNULL 생략 예시

UNIQUE

UNIQUE 제약 조건을 설정하면, 해당 필드는 서로 다른 값을 가져야 합니다.
즉, 이 제약 조건이 설정된 필드는 중복된 값을 저장할 수 없습니다.

UNIQUE 제약 조건은 CREATE 문으로 테이블을 생성할 때나, 나중에 ALTER 문으로 추가할 수도 있습니다.

1. CREATE TABLE 테이블이름
(
	필드명 필드타입 UNIQUE,
    ...
)

2. CREATE TABLE 테이블이름
(
	필드이름 필드타입,
    ...
    [CONSTRAINT 제약조건이름] UNIQUE (필드이름)
)

위의 두 문법 모두 해당 필드에 UNIQUE 제약조건을 설정합니다.

이때 두 번째 문법을 사용하면, 해당 제약 조건에 이름을 설정할 수 있습니다.

CREATE 시 Test 테이블을 생성하면서 ID 필드에 UNIQUE 제약조건을 설정하는 예시를 살펴보도록 하겠습니다.

CREATE TABLE Test 

(

    ID INT UNIQUE,

    Name VARCHAR(30),

    ReserveDate DATE,

    RoomNum INT

);

UNIQUE 예시

이렇게 ID 필드에 UNIQUE 제약조건을 설정한 후에 Test 테이블의 정보를 확인하면 다음과 같습니다.

PRIMARY KEY

PRIMARY KEY 제약 조건을 설정하면, 해당 필드는 NOT NULL과 UNIQUE 제약 조건의 특징을 모두 가집니다.
따라서 이 제약 조건이 설정된 필드는 NULL 값을 가질 수 없으며, 또한 중복된 값을 가져서도 안 됩니다.
이러한 PRIMARY KEY 제약 조건을 기본 키라고 합니다.

UNIQUE는 한 테이블의 여러 필드에 설정할 수 있지만, PRIMARY KEY는 테이블당 오직 하나만 설정할 수 있습니다.
이러한 PRIMARY KEY 제약 조건은 테이블의 데이터를 쉽고 빠르게 찾도록 도와주는 역할을 합니다.

PRIMARY KEY테이블의 각 레코드를 고유하게 식별합니다.
기본 키는 UNIQUE 값을 포함해야 하며 NULL 값을 포함할 수 없습니다.
테이블에는 하나의 PK(기본키)만 있을 수 있습니다.

CREATE시 PRIMARY KEY 제약조건을 설정하는 문법을 보도록 하겠습니다.

해당 필드의 타입 뒤에 PRIMARY KEY를 명시하면, 해당 필드가 기본 키로 설정됩니다.

1. CREATE TABLE 테이블이름

(

    필드이름 필드타입 PRIMARY KEY,

    ...

)
2. CREATE TABLE 테이블이름

(

    필드이름 필드타입,

    ...,

    [CONSTRAINT 제약조건이름] PRIMARY KEY (필드이름)

)

위의 두 문법 모두 해당 필드에 PK를 설정합니다.

이 때 두 번째 문법을 사용하면 해당 조건에 이름을 설정할 수 있습니다.

실제 쿼리와 생성된 테이블을 살펴보면 다음과 같습니다.

CREATE TABLE Test 

(

    ID INT PRIMARY KEY,

    Name VARCHAR(30),

    ReserveDate DATE,

    RoomNum INT

);

PK 예시

FOREIGN KEY

FOREIGN KEY 제약 조건을 설정한 필드는 외래 키라고 부르며, 한 테이블을 다른 테이블과 연결해주는 역할을 합니다.
외래 키가 설정된 테이블에 레코드를 입력하면, 기준이 되는 테이블의 내용을 참조해서 레코드가 입력됩니다.
즉, FOREIGN KEY 제약 조건은 하나의 테이블을 다른 테이블에 의존하게 만듭니다.

FOREIGN KEY 제약 조건을 설정할 때 참조되는 테이블의 필드는 반드시 UNIQUE나 PRIMARY KEY 제약 조건이 설정되어 있어야 합니다.

CREATE시 FORIGN KEY를 설정하는 문법을 살펴보겠습니다.

테이블을 생성할 때 해당 필드의 타입 뒤에 FOREIGN KEY를 명시하면, 해당 필드가 외래 키로 설정됩니다.

CREATE TABLE 테이블이름

(

    필드이름 필드타입,

    ...,

    [CONSTRAINT 제약조건이름]

    FOREIGN KEY (필드이름)

    REFERENCES 테이블이름 (필드이름)

)

참조되는 테이블의 이름은 REFERENCES 키워드 다음에 명시합니다.

Test2 테이블의 ParentID 필드에 Test1 테이블의 ID 필드를 참조하는 FOREIGN KEY 제약 조건을 설정하는 예시를 살펴보겠습니다.

CREATE TABLE Test2

(

    ID INT,

    ParentID INT,

    FOREIGN KEY (ParentID)

    REFERENCES Test1(ID) ON UPDATE CASCADE

);

FK 예시

ON DELETE, ON UPDATE

FOREIGN KEY 제약 조건에 의해 참조되는 테이블에서 데이터의 수정이나 삭제가 발생하면, 참조하고 있는 테이블의 데이터도 같이 영향을 받습니다.
이때 참조하고 있는 테이블의 동작은 다음 키워드를 사용하여 FOREIGN KEY 제약 조건에서 미리 설정할 수 있습니다.

참조되는 테이블의 값이 삭제될 경우의 동작은 ON DELETE 구문으로 설정할 수 있습니다.
또한, 참조되는 테이블의 값이 수정될 경우의 동작은 ON UPDATE 구문으로 설정할 수 있습니다.

이때 설정할 수 있는 동작은 다음과 같습니다.

1. CASCADE : 참조되는 테이블에서 데이터를 삭제하거나 수정하면, 참조하는 테이블에서도 삭제와 수정이 같이 이루어집니다.

2. SET NULL : 참조되는 테이블에서 데이터를 삭제하거나 수정하면, 참조하는 테이블의 데이터는 NULL로 변경됩니다.

3. NO ACTION : 참조되는 테이블에서 데이터를 삭제하거나 수정해도, 참조하는 테이블의 데이터는 변경되지 않습니다.

4. SET DEFAULT : 참조되는 테이블에서 데이터를 삭제하거나 수정하면, 참조하는 테이블의 데이터는 필드의 기본값으로 설정됩니다.

5. RESTRICT : 참조하는 테이블에 데이터가 남아 있으면, 참조되는 테이블의 데이터를 삭제하거나 수정할 수 없습니다.

DEFAULT

DEFAULT 제약 조건은 해당 필드의 기본값을 설정할 수 있게 해줍니다.
만약 레코드를 입력할 때 해당 필드 값을 전달하지 않으면, 자동으로 설정된 기본값을 저장합니다.

CREATE 시 Test 테이블을 생성하면서 Name 필드에 DEFAULT 제약조건을 이용하여 기본값을 설정하는 예시를 살펴보겠습니다.

CREATE TABLE Test

(

    ID INT,

    Name VARCHAR(30) DEFAULT 'Anonymous',

    ReserveDate DATE,

    RoomNum INT

);

위 쿼리의 결과로 생성된 테이블의 상세 정보는 아래와 같습니다.

NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, DEFAULT 와 같은 다양한 데이터베이스 제약조건에 대해 살펴보았습니다.

또 PK와 FK 설정시의 제약조건에 대해 알아보았습니다.

RDB를 이용해서 서비스를 구현할 때 기본이 되는 내용이므로

꼭 숙지하여 DB를 설계하고 사용하는 것이 좋을 것 같습니다.

참고: http://tcpschool.com

PORT 포트번호란

코딩하는 너구리 — Thu, 11 Aug 2022 08:29:40 +0900

IP와 함께 PORT 번호에 대해서 들어보았을 것이다.

TCP 프로토콜을 살펴볼 때 전송하는 패킷에 PORT 번호에 대한 정보가 포함되어 있었는데 PORT 번호가 무엇인지 간단하게 살펴보자.

포트 번호는 해당 IP주소가 가리키는 PC에 접속할 수 있는 통로이다.

예시를 들자면, A 아파트 이름을 IP 주소라고 할 때 00동 00호로 상세한 집 주소를 나타내는 것과 같은 역할을 하는게 PORT 번호라고 생각하면 쉬울 것 같다.

포트는 0번부터 65535번까지 있는데, 하나의 PC로 연결을 할때 포트 번호에 따라 6만 가지 이상으로 구분할 수 있다.

보통 0~1023번 포트는 잘 알려진 포트로 이미 사용되고 있거나, 상징성이 있기 때문에 해당 프로세스가 아닌 경우에는 다른 포트 번호를 사용하는게 일반적이다.

잘 알려진 포트의 예시는 아래와 같다.

이미 사용중인 포트는 중복해서 사용될 수 없으므로 포트 번호를 지정할 때 해당 포트가 사용중인지 확인이 필요하다.

참고 강의 : https://www.inflearn.com/course/http-웹-네트워크

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

TCP란?

코딩하는 너구리 — Wed, 10 Aug 2022 09:06:16 +0900

https://javacoding.tistory.com/160

IP(Internet Protocol)

내가 인터넷을 통해 정보를 원하는 곳으로 전달하고자 할 경우, 도착지를 알아야 한다. 나의 주소와 상대의 주소는 어떻게 나타낼 수 있을까? 이때 PC마다의 주소를 지정할 수 있도록 한게 IP 체

javacoding.tistory.com

이전 글에서 IP 프로토콜에 대해서 살펴보았는데, 조금 더 상위 계층의 TCP에 대해 간략히 알아보자.

패킷이 소실되거나, 전달 순서가 바뀌거나, 불확실한 상대에게 데이터를 전달하는 등 IP 프로토콜에서 데이터 전송을 신뢰할 수 없는 여러 문제가 있었다. TCP는 이런 문제의 상당 부분을 해결해줄 수 있다는 점에서 신뢰할 수 있는 프로토콜로 많이 알려져 있다.

https://developer.mozilla.org/ko/docs/Glossary/TCP

TCP 전송

TCP 전송은 어떻게 이루어질까? 여러 프로그래밍 언어에서 TCP를 위해 보통 SOCKET 라이브러리를 많이 이용하는데

SOCKET을 통해 상대 서버로 데이터를 전달하는 그림 을 간략히 살펴보자.

그림을 간략히 정리해보면

라이브러리를 통해 소켓을 만들고 메시지 데이터를 담는다.
OS 계층의 TCP 단계를 거치며 TCP 정보(출발지PORT, 목적지 PORT, 전송 제어, 순서, 기타…)들을 생성하여 메시지 데이터에 추가한다.
IP단계를 거치며 IP 정보(출발지IP, 목적지IP, 기타…)를 메시지 데이터에 추가한다.
생성된 IP 패킷에 Ethernet frame정보를 추가한다.
인터넷을 통해 상대 서버로 전달한다.

TCP 특징

TCP는 전송 제어 프로토콜(Transmission Control Protocol, TCP)이라고도 하는데 특징은 다음과 같다.

연결지향 - 3 way handshake

TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용한다. TCP 3 way Handshake는 TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 목적지 서버와의 연결을 진행하는 것이다.
3 way handshaking을 통해 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 데이터 전달이 시작하기 전에 상대쪽이 준비가 되었는지 확인해볼 수 있다.

출처: https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-22편-TCP-3-WayHandshake-4-WayHandshake

2. 데이터 전달 보증

목적지에서 TCP 데이터가 도착하면 출발지쪽으로 메시지 도착을 알린다.

이 때 반환하는 것을 ACK라고 하며, TCP 헤더에 ACK 관련 정보를 넣은 TCP 세그먼트를 반환한다.

그러면 출발지쪽은 ACK가 돌아오는 것을 보고 전송한 메시지가 무사히 목적지에 도착했다는 것을 알 수 있다.

만약 ACK가 오지 않는다면 문제가 발생한 것으로 보고 재전송, 재연결 등의 처리를 할 수 있다.

TCP에서는 이렇게 ACK를 통해 데이터가 전달되었다는 것을 보증받을 수 있다.

3. 순서 보장

TCP 전송에서는 순서가 보장된다. TCP 세그먼트에 Sequence Number를 붙여 구현하기 때문인데,

수신쪽에서는 수신한 세그먼트를 바로 전달하지 않고, 버퍼에 가지고 있다가 Sequence Number를 사용해서 세그먼트가 순서가 맞을때까지 기다린다. 이 순서가 맞춰진 세그먼트 data chunk를 결합시킨 후 전달한다.

기본적인 TCP의 개념과 특징들에 대해서 살펴보았는데 정리해보면 IP 프로토콜에 비해 TCP는 더 신뢰적이고 안정적이었다.

3-way handshaking 과정으로 연결지향적이었고, ACK를 이용하여 데이터가 전달되었는지 보증받을 수 있었으며, Sequence Number를 이용하여 전달하는 데이터들의 순서를 보장해주는 특징이 있었다.

참고 강의 : https://www.inflearn.com/course/http-웹-네트워크

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

IP(Internet Protocol)

코딩하는 너구리 — Wed, 3 Aug 2022 08:31:56 +0900

내가 인터넷을 통해 정보를 원하는 곳으로 전달하고자 할 경우, 도착지를 알아야 한다.

나의 주소와 상대의 주소는 어떻게 나타낼 수 있을까?

이때 PC마다의 주소를 지정할 수 있도록 한게 IP 체계이다.

PC마다 지정된 IP 주소가 있기 때문에 우리는 목적지의 IP 주소로 정보를 보낼 수 있다.

HTTP 통신시에는 패킷(Packet)이라는 통신 단위를 사용하는데 간략하게 그림으로 나타내면 아래와 같다.

IP 패킷에는 출발지 IP, 목적지 IP와 같은 수많은 정보들로 이루어져 있다.

IP와 함께 사용하는 PORT 주소는 뭘까?

https://javacoding.tistory.com/163

PORT 포트번호란

IP와 함께 PORT 번호에 대해서 들어보았을 것이다. TCP 프로토콜을 살펴볼 때 전송하는 패킷에 PORT 번호에 대한 정보가 포함되어 있었는데 PORT 번호가 무엇인지 간단하게 살펴보자. 포트 번호는 해

javacoding.tistory.com

내가 100.100.100.1 에서 특정 웹 서버인 200.200.200.2로 정보를 보낸다고 할때

패킷안에 출발지와 목적지에 대한 정보가 있기 때문에 노드들은 전달해줄 수 있는 다음 노드에게 패킷을 전달하고 여러 노드를 거쳐 목적지까지 정보가 전송된다.

실제로 우리가 웹 사이트에 접속하거나 API 요청을 할때 IP 주소로 요청을 하는 경우는 드물다. IP 프로토콜의 한계가 있기 때문인데,

IP 전송 방식의 특징을 살펴보면 다음과 같다.

첫 번째는 비연결성이다.

패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 목적지까지 전달한다. 목적지 주소가 잘못되어도 목적지까지 정보를 전달하는 것이다. 이런 경우에 목적지에서는 데이터를 전달 받지 못하게 됩니다.

두 번째는 비신뢰성이다.

비신뢰성이란 송신자가 전송한 패킷의 손상여부를 송신자와 수신자가 알 수 없으며 패킷 전달 순서가 보장되지 않는다는 것을 의미합니다.

비연결성은 서로 연결되지 않은 송신자와 수신자간의 데이터를 전달하는 특징이며 비신뢰성은 IP 프로토콜이 전송하는 정보가 정확하게 전달되었는지 확인하지 않는 것이다.

따라서 신뢰성있는 통신을 하기 위해서는 상위 레이어의 TCP와 같은 프로토콜을 활용해야 한다.

https://javacoding.tistory.com/162

TCP(Transmission Control Protocol) 프로토콜

javacoding.tistory.com

참고 강의 : https://www.inflearn.com/course/http-웹-네트워크

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

Flutter DEBUG mark 지우기

코딩하는 너구리 — Sat, 25 Jun 2022 12:24:13 +0900

Flutter 개발 중에 시뮬레이터를 사용해서 테스트 하다 보면 우측 상단에 DEBUG가 적힌 리본이 보이는 것을 확인할 수 있다.

가끔 모바일 기기에서 테스트 해보기도 하는데 이 마크가 은근 거슬린다.

제거 방법은 간단한데, 코드에 설정 한 줄만 적어두면 된다.

debugShowCheckedModeBanner 라는 옵션을 false 로 설정해주면 사라진다.

Flutter - const Constructor

코딩하는 너구리 — Sun, 12 Jun 2022 15:43:24 +0900

Flutter를 공부하다가 const constructor에 대해서 알게 되었다. 알아둘 만한 내용이어서 기록해둘까 한다.

정확히 말하면 Dart언어의 const constructor인데, 가장 쉬운 예시는 다음과 같다.

const var title = const Text('Hi!')

const를 왜 쓸까?

const 생성자를 사용하는 이유는 최적화이다.

컴파일러는 모든 const 객체에 대해 동일한 메모리 부분을 할당하여 객체를 불변으로 만든다. 쉽게 말하면 const로 지정해두면

앱을 실행할 때 한 번만 생성한다는 것인데, 한 번만 만들기 때문에 리소스 낭비를 하지 않는다는 것이다.

const와 관련해서 가장 많이 비교하는게 const와 final이 있는데, 간단히만 적어두자.

먼저 dart 언어에는 final과 const가 있다.

두 가지의 공통점은 '한 번 설정한 값을 변경할 수 없다. 다른 값으로 변경하려고 시도하면 컴파일 오류가 발생한다.'

하지만 두 방식의 차이점으로는 const의 경우, 컴파일 타임에서 상수를 정의한다.

컴파일 타임에서 정의하고, 런타임에서 상수는 정의할 수 없다.

예를 들어 보자면, Datetime.now()로 정의되는 값은, 런타임에서 결정된다.

그렇기 때문에 final로 Datetime.now()를 정의할 수 있지만, const로는 정의할 수 없다.

const는 그럼 언제 쓰는게 좋을까?

코드 내에서 setState()를 사용할 경우가 굉장히 많아질텐데, setState()를 실행하면 범위에 해당하는 변수들이 모두 재생성된다.

Text()와 같은 정해진 상수의 경우에는 매번 재생성하는 것이 내부 리소스를 낭비하는 것이기 때문에, 이럴 때에는 const를 사용하여 자원을 낭비하지 않도록 해주는 것이 좋다.

const Text('build',)

간단히 Text 뿐만 아니라 간단한 Widget의 경우에도 const로 정의할 수 있기 때문에,

const 정의가 가능한 경우에는 const를 사용하도록 하자.

오스윗리버 1박 2일 후기 (+글램핑)

코딩하는 너구리 — Sun, 24 Oct 2021 23:46:42 +0900

안녕하세요 ~
이번에 회사에서 연수원으로 사용하는 곳을
숙박시설로 사용할 수 있다고 하여!!
신청을 한 뒤에 당첨 안내를 받고
오스윗리버에 다녀오게 되었습니다

3시에 체크인을 한 후 저희가 묵을 숙소는
타워형 302호!
들어가자마자 거실에서 보이는 뷰는
끝내주더라구요

숙소에 집기류, 오븐, 세탁기 등등 거의 대부분이 비치되어 있었구요, 그 중 정수기가 있어서 너무 편리했습니다!!

방은 3개, 화장실은 2개였습니다
안방에 있는 화장실에 욕조가 있었구요
거실에 있는 다른 한개는 욕조가 없었습니다!

아래 사진에 보이는 방에 킹사이즈 침대와
욕조가 있는 화장실, 드레스룸, TV가 설치되어있었습니다! 완벽하더라구요
뷰까지 나이스..!

안방에 있는 화장실 욕조 뷰가 끝내줍니다

다시 보는 거실 뷰

저희는 글램핑도 예약했는데요
신청할 때엔 저녁 7-8시로 예약했는데
도착해서 안내 받을때는
오후 4-7라고 안내해주시더라구요
(이 부분은 저희도 잘 모르는 부분이라
확인을 꼭 하고 가시는 것이 좋을 것 같습니다)

글램핑장은 총 3개였습니다
글램핑 안에 내부는 이렇구요
블루투스 스피커, 냉난방기,
집게, 가위, 숯, 번개탄, 토치가 구비되어 있었습니다

** 쿠킹호일이 없으니 꼭 준비를 해가셔야 합니다!

일회용 접시, 일회용 숟가락, 젓가락, 컵을 넉넉히
챙겨오시는 것을 추천드립니다

호일이 없어서 그을음이 올라와 약간의 어려움이
있었지만 그조차도 잊게해주는 맛이었어요ㅠㅠ
분위기도 최고..❤️❤️
호일을 가져왔더라면 이것저것 더 구워먹을 수 있었을 것 같아요!

사용 시간이 다 되어 방에 들어와 2차전을 벌였습니다
ㅋㅋㅋㅋ

여기까지는 좋았는데..
정말 아쉬운 딱 한가지 문제점이 있더라구요

바로 이곳엔 수건이 없었다는 점입니다..

호텔이 아닌 연수원이라 곰곰히 생각해보면
그럴 수 있겠다 싶었지만
안내사항에 그런 문구가 없었기에
챙겨오질 않아서 당황했어요!! ☹️

근처에 편의점이 있는지 부랴부랴 찾아봤는데
걸어가기엔 너무 먼 거리더라구요
근처에 편의점이 없습니다ㅜㅜ 마트도요
물론 차로 가면 가깝습니다!
여차저차 해서 편의점에서 수건을 구했지만
집에서 사용하는 수건만큼 안닦여요..^^
물기가 그대로..ㅠ

방에서 배부르게 쉰 후에 새벽에 나와서 하늘을 보니
별이 정말 잘 보였습니다
하늘이 깨끗했나봐요

북한강 바로 앞에 있는 숙소라
산책 겸 어딜 걸어도 장관이고 포토존 되더라구요
해질녘 노을까지 더해지면 금상첨화
ㅋㅑ~~~

저희가 간 날은 10월 말이라 추웠는데요
숙소 거실에 이런 벽난로가 있어서
너무너무너무 좋았습니다
(진짜 벽난로는 아니구요 ㅋ 히터가 나오더라고요)
이 벽난로 하나로
숙소에 감성 100방울 떨어뜨린 느낌!!!

난방도 잘 되고 뭐 하나 부족한 점 없이
제대로 힐링하고 와서 너무 만족했던
오스윗리버였습니다

다음에 또 당첨되면
수건, 호일 꼭꼭 챙겨서 오고싶네요
재방문 의사 100000입니다

도움이 되셨으면 좋겠어요!!!

금강산 감자탕(방이직영점) 추천해요

코딩하는 너구리 — Wed, 18 Aug 2021 19:55:55 +0900

감자탕 부시고 왔습니다!!!!!!!

올림픽공원 들꽃마루에서 사진찍고

저녁을 먹기 위해 향한 금강산 감자탕!

저희는 방이직영점으로 다녀왔습니다 ㅎㅎ

여섯시 좀 안되서 도착했는데 거의 만석이더라구요

2명이서 일단 감자탕 소짜리를 시켜보았습니다

29000원이었어요! 감자탕을 많이 먹어보지 않아 잘 몰랐지만, 가격대비 엄청 푸짐하다고 느꼈어요!

기본 반찬은 심플합니다 ㅎㅎ

양이 미쳤어요.....

고기도 맛있고 감자도 많구 국물도 끝내주고요ㅠ

고기를 드시면서 국물을 계속 끓이시면

국물이 점점 진해지는데.. 소주 그냥 들어갑니다

(또 먹고싶어요 )

저희 둘은 많이 먹는 편인데도 불구하고 ㅋㅋ

배불러서 토할뻔했어요 (심지어 아침점심도 안먹음)

볶음밥도 못먹었어요..............

ㅋㅋㅋ 싹슬이..

올림픽공원 들꽃마루와 별로 멀지 않아

데이트 하시고 점심 저녁으로

드시러 가시길 추천드릴게요!

석촌호수와도 별로 멀지 않더라구요

방문했을 때 있었던 스티키몬스터랩 (졸귀ㅠㅠ)

이상 금강산 감자탕 리뷰였습니다~~

다시 한 번 외칠게요 존맛탱구리~~~~!~!~!~!

용인 파스타 맛집 다니식당

코딩하는 너구리 — Wed, 18 Aug 2021 19:36:35 +0900

매운 새우 크림 파스타

다니식당에는 파스타 종류가 참 다양한데요

이번에는 매운 새우 크림 파스타를 먹어봤습니다!ㅎㅎㅎ

보시다시피 매운 향과 맛이 있어서 전혀 느끼하지 않고

담백한게 제 입맛에 완전 잘맞았아요

로제 치킨 파스타

그리고 두번째 메뉴는 바로 요놈 로제 치킨 파스타입니다

크림 파스타랑은 다른 로제맛 파스타인데요, 일반 엽떡이나 치킨에 들어가는 로제랑 차원이 다른

찐 로제맛 나는 파스타입니다

용인 역북동 명지대 앞 맛집

저는 용인 역북 근처에 거주하고 있는 명지대생 입니다 ✌

앞으로 졸업하기 전까지 용인 맛집에 대해 자주 올려볼게용

여긴 실패한 적 없는 용인 찐맛집이에요

단, 꾸덕한 파스타 좋아하시는 분들에겐 다소 소스가 묽을수도 있다는 점~ 그렇다고 간이 약하거나 그러진 않아요!

(제가 바로 그 꾸덕한 파스타 좋아하는 1인..)

그래도!

파스타 드시고 싶은 분들께 강추

분위기도 아늑하니 좋더라구여

(양도 많음)

역북동에 생긴건 많은데 뭐 먹지 하시는 분들은 당장 다니식당으로 달려가세요~~~~~~!

Netty 에코 서버-클라이언트 구현 (feat. 네트워크 소녀 Netty)

코딩하는 너구리 — Thu, 7 Jan 2021 12:34:25 +0900

에코 서버 구현

Netty 를 이용하여 에코 서버를 만들어보자.

통상적으로 네트워크 프로그램을 배울 때 가장 처음 예제로 에코 서버를 사용하는데

그 이유는 프로그램의 구현이 간단할 뿐만 아니라 입출력 또는 송수신이라는 기본적인 동작 방식을 이해하는 데 유용하기 때문이다.

먼저 Server 쪽 코드를 작성해보자.

8888번 포트를 사용하여 클라이언트의 연결을 대기하고,

클라이언트 접속 요청에 의해 소켓 채널을 만들고, 소켓으로 데이터가 들어온다면 지정된 EchoServerHandler가 되돌려주는 간단한 예제이다.

// 에코 서버

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.*;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;

public class EchoServer {
    public static void main(String[] args) throws InterruptedException {
        EventLoopGroup bossGroup = new NioEventLoopGroup(1);
        EventLoopGroup workerGroup = new NioEventLoopGroup();

        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        public void initChannel(SocketChannel ch) {
                            ChannelPipeline p = ch.pipeline();
                            p.addLast(new EchoServerHandler());
                        }
                    });
            ChannelFuture f = b.bind(8888).sync();
            f.channel().closeFuture().sync();
        } finally {
            workerGroup.shutdownGracefully();
            bossGroup.shutdownGracefully();
        }
    }
}

다음은, 서버로 입력된 데이터를 클라이언트에게 에코시키기 위해 필요한 에코 서버 핸들러 코드이다.

channelRead 메서드에서 수신된 메시지를 write()하고,

write() 작업이 모두 완료된 후 channelReadComplete() 메서드를 호출하여 클라이언트로 메시지 데이터를 보내준다.

package com.netty.test;

import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.SimpleChannelInboundHandler;
import io.netty.util.concurrent.EventExecutorGroup;

import java.nio.charset.Charset;

public class EchoServerHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        String readMessage = ((ByteBuf) msg).toString(Charset.defaultCharset());
        System.out.println("수신한 문자열 [" + readMessage + "]");
        ctx.write(msg);
    }

    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
        ctx.flush();
    }
}

구현한 에코 서버 핸들러의 주요 기능은 다음과 같다.

입력된 데이터를 처리하는 이벤트 핸들러인 ChannelInboundHandlerAdapter를 상속받게 지정한다.
channelRead는 데이터 수신 이벤트 처리 메서드다. 클라이언트로부터 데이터의 수신이 이루어졌을 때 네티가 자동으로 호출하는 이벤트 메서드다.
수신된 데이터를 가지고 있는 네티의 바이트 버퍼(ByteBuf) 객체로부터 문자열 데이터를 읽어온다.
수신된 문자열을 콘솔로 출력한다.
ctx는 ChannelHandlerContext 인터페이스의 객체로서 채널 파이프라인에 대한 이벤트를 처리한다.
- 여기서는 서버로 연결된 클라이언트 채널로 입력받은 데이터를 그대로 전송하는 역할을 한다.
channelRead 이벤트의 처리가 완료된 후 자동으로 수행되는 이벤트 메서드인 channelReadComplete() 메서드를 이용해 채널 파이프라인에 저장된 버퍼를 전송하는 flush 메서드를 호출한다.

이렇게 에코 서버 구현을 완료하였습니다.

이제 에코 클라이언트도 구현해보도록 하겠습니다.

클라이언트 프로그램은 에코 서버 8888번 포트로 접속하여 "Hello Netty !"라는 문자열을 전송하고 서버의 응답을 수신하도록 해보자.

이어서 수신한 데이터를 화면에 출력하고 연결된 소켓을 종료한다.

클라이언트 코드도 서버와 마찬가지로 main 메서드가 포함된 EchoClient와 데이터 핸들러인 EchoClientHandler로 구성된다.

// 에코 클라이언트

import io.netty.bootstrap.Bootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelPipeline;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;

public class EchoClient {
    public static void main(String[] args) throws Exception{
        EventLoopGroup group = new NioEventLoopGroup();

        try {
            Bootstrap b = new Bootstrap();
            b.group(group)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        public void initChannel(SocketChannel ch) throws Exception {
                            ChannelPipeline p = ch.pipeline();
                            p.addLast(new EchoClientHandler());
                        }
                    });
            ChannelFuture f = b.connect("localhost", 8888).sync();
            f.channel().closeFuture().sync();
        } finally {
            group.shutdownGracefully();
        }
    }
}

클라이언트의 main 코드는 서버의 구조와 거의 같다.

이벤트 루프, 부트스트랩, 채널 파이프라인, 핸들러 등을 초기화하는 부분은 서버 부분과 거의 동일하다.

서버와 다르게 이벤트 루프 그룹을 하나만 설정했다.
- 클라이언트 애플리케이션은 서버에 연결된 채널 하나만 존재하기 때문에 이벤트 루프 그룹이 하나다.
클라이언트 애플리케이션이 생성하는 채널의 종류를 설정한다. 여기서는 NIO 소켓 채널인 NioSocketChannel을 설정했다.
채널 파이프라인의 설정에 일반 소켓 채널 클래스인 SocketChannel을 설정한다.
비동기 입출력 메서드인 connect()를 호출한다. connect 메서드는 메서드의 호출 결과로 ChannelFuture 객체를 돌려주는 이 객체를 통해서 비동기 메서드의 처리 결과를 확인할 수 있다.
- ChannelFuture 객체의 sync 메서드는 ChannelFuture 객체의 요청이 완료될 때까지 대기한다. 단, 실패시에는 예외를 던진다.

다음으로 에코 클라이언트 데이터 핸들러를 구현해보자.

// 클라이언트 핸들러

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.util.concurrent.EventExecutorGroup;

import java.nio.charset.Charset;

public class EchoClientHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        String sendMessage = "Hello, Netty !";

        ByteBuf messageBuffer = Unpooled.buffer();
        messageBuffer.writeBytes(sendMessage.getBytes());

        StringBuilder builder = new StringBuilder();
        builder.append("전송한 문자열 [");
        builder.append(sendMessage);
        builder.append("]");

        System.out.println(builder.toString());
        ctx.writeAndFlush(messageBuffer);
    }

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        String readMessage = ((ByteBuf)msg).toString(Charset.defaultCharset());

        StringBuilder builder = new StringBuilder();
        builder.append("수신한 문자열 [");
        builder.append(readMessage);
        builder.append("]");

        System.out.println(builder.toString());
    }

    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
        ctx.close();
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        super.exceptionCaught(ctx, cause);
        ctx.close();
    }
}

서버와 클라이언트 두 핸들러 모두 ChannelInboundHandlerAdapter를 상속하며 구현했는데,

클라이언트 핸들러에는 channelActive 를 추가했다. 주요 설명은 다음과 같다.

ChannelActive 이벤트는 소켓 채널이 활성화되었을 때 실행된다.
writeAndFlush 메서드는 내부적으로 데이터 기록과 전송의 두 가지 메서드를 호출한다.
서버로부터 수신된 데이터가 있을 때 channelRead가 호출된다.
수신된 데이터를 모두 읽었을 때 channelReadComplete가 호출된다.
수신된 데이터를 모두 읽은 후 서버와 연결된 채널을 닫는다.

이로써 서버와 클라이언트 코드 작성을 완료했다.

// 에코 서버 실행 결과
수신한 문자열 Hello, netty !

// 에코 클라이언트 실행 결과
전송한 문자열 Hello, netty !
수신한 문자열 Hello, netty !

네티에서 데이터 송신을 아웃바운드 이벤트, 데이터 수신을 인바운드 이벤트로 정의하고 있다.

인바운드 이벤트와 아웃바운드 이벤트는 모두 프로그램을 기준으로 정의된다.

출처 : book.naver.com/bookdb/book_detail.nhn?bid=9608322

자바 네트워크 소녀 Netty

자바 네트워크 프로그래밍의 최고의 선택 NETTY!이 책은 안정성과 성능을 세계적으로 인정받아 카카오톡, 애플, 트위터, 페이스북, 네이버 라인 등에서 사용하는 자바 네트워크 프레임워크 네티

book.naver.com

Netty 코덱

코딩하는 너구리 — Tue, 5 Jan 2021 22:06:25 +0900

코덱(codec)이란?

네트워크에서는 데이터를 단순한 원시 바이트의 연속으로 취급하지만 애플리케이션에서는 이러한 바이트를 의미 있는 정보 구조로 만들어야 한다.

애플리케이션 데이터와 네트워크 포맷 간의 변환을 수행하는 컴포넌트를 각각 인코더와 디코더라고 하며, 두 기능을 모두 가진 단일 컴포넌트를 코덱이라고 한다.

인코더는 메시지를 전송하기에 적합한 형식으로 변환하며,

디코더는 네트워크 스트림을 다시 프로그램의 메시지 포맷으로 변환한다.

인코더는 아웃바운드 데이터를 처리하며

디코더는 인바운드 데이터를 처리한다.

디코더

네티의 디코더 클래스는 고유한 두 사용 사례를 지원한다.

바이트 스트림을 메시지로 디코딩 : ByteToMessageDecoder 및 ReplayingDecoder
메시지를 다른 메시지 유형으로 디코딩 : MessageToMessageDecoder

디코더는 인바운드 데이터를 다른 포맷으로 변환하는 일을 하므로 네티의 디코더는 자연스럽게 ChannelInboundHandler를 구현한다.

디코더는 언제 이용할까?

인바운드 데이터를 ChannelPipeline 내의 다음 ChannelInboundHandler를 위해 변환할 때 이용한다.

ByteToMessageDecoder

바이트 스트림을 메시지로 디코딩하는 작업은 매우 일반적이므로 네티는 이 작업을 위한 기본 클래스인 ByteToMessageDecoder를 제공한다.

원격 피어가 완성된 메시지를 한번에 보낼지는 알 수 없으므로,

인바운드 데이터가 처리할 만큼 모일 때까지 버퍼에 저장한다.

decode(CHannelHandlerContext ctx, ByteBuf in, List out) 메서드는

ByteBuf에 읽을 바이트가 없을 때까지 반복하고

List가 비어 있지 않은 경우 그 내용을 파이프라인의 다음 핸들러로 전달한다.

인바운드 ByteBuf에서 4바이트씩 읽고, 이를 int로 디코딩한 후 List로 추가한다.

List에 추가할 항목이 더 이상 없는 경우 그 내용을 담아 ChannelInboundHandler로 전달한다.

public class ToIntegerDecoder extends ByteToMessageDecoder {
    @Override
    public void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        if(in.readableBytes() >= 4) {
            out.add(in.readInt());
        }
    }
}

MessageToMessageDecoder

decode(CHannelHandlerContext ctx, I msg, List out)

I는 msg 인수의 형식, Object는 디코딩 후 추가될 List이다.

public class IntegerToStringDecoder extends MessageToMessageDecoder<Integer> {
    @Override
    public void decode(ChannelHandlerContext ctx, Integer msg, List<Object> out) throws Exception {
    out.add(String.valueOf(msg));
    }
}

인코더

인코더는 ChannelOutboundHandler를 구현하고 아웃바운드 데이터를 한 포맷에서 다른 포맷으로 변환하며, 디코더의 반대 기능을 수행한다.

메시지를 바이트로 인코딩
메시지를 메시지로 인코딩

public class ShortToByteEncoder extendss MessageToByteEncoder<Short> {
    @Override
    public void encode(ChannelHandlerContext ctx, Short msg, ByteBuf out) throws Exception {
        out.writeShort(msg);    // Short를 ByteBuf에 기록
    }
}

출처 : 네티인 액션

https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

네티는 복잡한 네트워킹, 멀티스레드, 동시성을 관리하는 자바 기반 네트워킹 프레임워크로서, 반복적인 저수준 코드를 내부로 감춤으로써 비즈니스 논리를 분리하고 쉽게 재사용할 수 있게 해

book.naver.com

Netty ChannelHandler와 ChannelPipeline

코딩하는 너구리 — Sun, 3 Jan 2021 23:53:04 +0900

이미 앞부분에서 ChannelPipeline안에 ChannelHandler를 체인으로 연결해 처리 논리를 구성할 수 있다는 것을 배웠다. 이러한 클래스와 연관된 사용사례들과 ChannelHandlerContext에 대해서도 알아보자.

Channel의 수명주기

Channel 인터페이스는 ChannelInboundHandler API와 밀접한 관계가 있으며 간단하지만 유용한 상태 모델을 정의한다.

Channel의 네 가지 상태에 대해 알아보자.

상태	설명
ChannelUnregistered	Channel이 생성됐지만 EventLoop에 등록되지 않음
ChannelRegistered	Channel이 EventLoop에 등록됨
ChannelActive	Channel이 활성화됨(원격 피어로 연결됨). 이제 데이터를 주고받을 수 있음
ChannelInactive	Channel이 원격 피어로 연결되지 않음

Channel의 일반적인 생명 주기는

ChannelRegistered ==> ChannelActive ==> ChannelInactive ==> ChannelUnregistered 이다.

ChannelHandler 수명주기

Channelhandler 인터페이스에서 정의하는 수명주기 메서드에 대해 알아보자. 이러한 메서드는 ChannelHandler가 ChannelPipeline에 추가 또는 제거된 후 호출된다. 각 메서드는 ChannelHandlerContext 인수를 받는다.

메서드	설명
handlerAdded	Channelhandler가 ChannelPipeline에 추가될 때 호출됨.
handlerRemoved	Channelhandler가 ChannelPipeline에서 제거될 때 호출됨.
exceptionCaught	ChannelPipeline에서 처리 중에 오류가 발생하면 호출됨.

네티는 다음과 같이 ChannelHandler의 가장 중요한 하위 인터페이스를 정의한다.

ChannelInboundHandler
- 모든 유형의 인바운드 데이터와 상태 변경을 처리한다.
ChannelOutboundHandler
- 아웃바운드 데이터를 처리하고 모든 작업의 가로채기를 허용한다.

다음으로 이러한 ChannelInboundHandler와 ChannelOutboundHandler에 대해 알아보자.

ChannelInboundHandler 인터페이스

메서드	설명
channelRegistered	Channel이 EventLoop에 등록되고 입출력을 처리할 수 있으면 호출됨
channelUnregistered	Channel이 EventLoop에서 등록 해제되고 입출력을 처리할 수 없으면 호출됨
channelActive	Channel의 연결과 바인딩이 완료되어 활성화되면 호출됨
channelInactive	Channel이 활성 상태에서 벗어나 로컷 피어에 대한 연결이 해제되면 호출됨
channelReadComplete	Channel에서 읽기 작업이 완료되면 호출됨
channelRead	Channel에서 데이터를 읽을 때 호출됨
channelWritabilityChanged	Channel의 기록 가능 상태가 변경되면 호출된다.
userEventTriggered	POJO가 ChannelPipeline을 통해서 전달돼서 ChannelInboundHandler.fireUserEventTriggered()가 트리거되면 호출됨.

ChannelInboundHandler 구현이 channelRead()를 재정의하는 경우 풀링된 ByteBuf 인스턴스의 메모리를 명시적으로 해제하는 역할을 맡는다.

네티는 다음 예제와 같이 메모리를 해제할 수 있는 ReferenceCountUtil.release() 메서드를 제공한다.

@Sharable
public class DiscardHandler extends ChannelInboundHandlerAdapter {    // ChannelInboundHandlerAdapter를 확장
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {    // 수신한 메시지를 삭제
        ReferenceCountUtil.release(msg);
    }
}

네티는 해제되지 않은 리소스를 WARN 수준 로그 메시지로 로깅하므로 코드에 문제가 되는 인스턴스가 있으면 쉽게 발견할 수 있다. 그러나 이렇게 매번 리소스를 관리하기는 번거로울 수 있으며, SimpleChannelInboundHandler를 이용하면 더 쉽게 리소스를 관리할 수 있다. 다음 예제를 보자.

@Sharable
public class SimpleDiscardhandler extends SimpleChannelInboundHandler<Object> {    // SimpleChannelInboundHandler를 확장
    @Override
    public void channelRead0(ChannelHandlerContext ctx, Object msg) {
        // 다른 조치를 취할 필요가 없음
    }
}

SimpleChannelInboundHandler는 리소스를 자동으로 해제하므로 메시지의 참조도 무효화된다. 즉, 메시지의 참조를 저장해 나중에 이용하려고 하면 안 된다.

ChannelOutboundHandler 인터페이스

아웃바운드 작업과 데이터는 ChannelOutboundHandler에 의해 처리되며, 여기에 포함된 메서드는 Channel, ChannelPipeline, ChannelHandlerContext에서 이용된다.

ChannelOutboundHandler는 주문식으로 작업이나 이벤트를 지연하는 강력한 기능이 있어 정교하게 요청을 처리할 수 있다. 예를 들어 원격 피어에 대한 기록이 일시 중단된 경우 플러시 작업을 지연하고 나중에 재개할 수 있다.

ChannelOutboundHandler 메서드

메서드	설명
bind(ChannelHandlerContext, SocketAddress, ChannelPromise)	Channel을 로컬 주소로 바인딩 요청 시 호출됨
connect(ChannelHandlerContext, SocketAddress, SocketAddress, ChannelPromise)	Channel을 원격 피어로 연결 요청 시 호출됨
disconnect(ChannelHandlerContext, ChannelPromise)	Channel을 원격 피어로부터 연결 해제 요청 시 호출됨
close(ChannelhandlerContext, ChannelPromise)	Channel을 닫는 요청 시 호출됨
deregister(ChannelHandlerContext, ChannelPromise)	Channel을 EventLoop에서 등록 해제 요청 시 호출됨
read(ChannelHandlerContext)	Channel에서 데이터를 읽기 요청 시 호출
flush(ChannelHandlerContext)	Channel을 통해 원격 피어로 큐에 있는 데이터의 플러시 요청 시 호출됨
write(ChannelHandlerContext, Object, ChannelPromise)	Channel을 통해 원격 피어로 데이터 기록 요청 시 호출됨

`ChannelPromise와 ChannelFuture 비교`

ChannelOutboundHandler에 있는 대부분의 메서드에는 작업이 완료되면 알림을 전달받을 ChannelPromise 인수가 있다. ChannelPromise는 ChannelFuture의 하위 인터페이스로서 setSuccess()나 setFailure() 같은 기록 가능 메서드를 정의해 ChannelFuture를 읽기 전용으로 만든다.

리소스 관리

ChannelInboundHandler.channelRead() 또는 ChannelOutboundHandler.write()를 호출해 데이터를 대상으로 작업할 때는 리소스 누출이 발생하지 않게 주의해야 한다.

네티는 참조 카운팅을 이용해 풀링되는 ByteBuf를 관리한다. 네티는 잠재적인 문제 진단을 돕기 위해 애플리케이션 버퍼 할당의 약 1%를 샘플링해 메모리 누출을 검사하는 ResourceLeakDetector 클래스를 제공한다.

인바운드 메시지를 소비하는 쉬운 방법

인바운드 데이터를 소비하고 해제하는 것은 아주 흔한 작업이다. 네티는 이 작업을 위해 SimpleChannelInboundHandler라는 특수한 ChannelInboundHandler 구현을 제공한다. 이 구현은 메시지가 ChannelRead0()에서 소비되면 자동으로 메시지를 해제한다.

인바운드 핸들러를 활용할 때 기본적으로 SimpleChannelInboundHandler를 사용하는 습관을 들여 손쉬운 리소스 관리를 하도록 하자.

아웃바운드에서의 리소스 관리

아웃바운드 핸들러에서는 write() 작업을 처리하고 메시지를 폐기하는 경우 직접 메시지를 해제해야 한다.

또한 리소스를 해제하는 것 뿐만 아니라 ChannelPromise에 알리는 것도 중요하다.

ChannelFutureListener가 메시지가 처리된 것에 대한 알림을 받지 못하는 경우가 생길 수 있기 때문이다.

따라서, 정리하자면 메시지가 소비 또는 폐기되어 다음 ChannelOutboundHandler로 전달되지 않는 경우 직접 ReferenceCountUtil.release()를 호출해야 한다. 전송 레이어에 도달한 메시지는 기록될 때 또는 Channel이 닫힐 때 자동으로 해제된다.

ChannelPipeline

ChannelPipeline을 Channel을 통해 오가는 인바운드와 아웃바운드 이벤트를 가로채는 Channelhandler 인스턴스의 체인이라고 생각하면, Channelhandler의 상호작용을 쉽게 이해할 수 있다.

새로운 Channel이 생성될 때마다 새로운 Pipeline이 생성된다. 이 연결은 영구적이며 Channel을 다른 ChannelPipeline과 연결하거나 현재 연결을 해제할 수 없다.

다음 사항들을 기억해두자.

ChannelPipeline은 한 Channel과 연결된 여러 ChannelHandler를 포함한다.
필요에 따라 동적으로 ChannelHandler를 추가하고 제거해 동적으로 ChannelPipeline을 수정할 수 있다.
ChannelPipeline에는 인바운드와 아웃바운드 이벤트에 반응해 작업을 호출하는 풍부한 API가 있다.

ChannelHandlerContext

ChannelHandler는 ChannelHandlerContext를 이용해 해당 ChannelPipeline 및 다른 핸들러와 상호작용할 수 있다. ChannelPipeline의 다음 ChannelHandler에 알림을 전달하는 것은 물론, 속해 있는 ChannelPipeline을 동적으로 수정할수도 있다.

Channel이나 ChannelPipeline 인스턴스에서 호출하면 메서드가 전체 파이프라인을 통해 전파된다.

반면 동일한 메서드를 ChannelHandlerContext에서 호출하면 현재 연결된 ChannelHandler에서 시작하며 파이프라인에서 이벤트를 처리할 수 있는 다음 ChannelHandler로만 전파된다.

따라서 이벤트 흐름이 짧은 ChannelHandlerContext를 잘 활용하면 성능상 이익을 거둘 수 있다.

Channel, ChannelPipeline, ChannelHandlerContext에 있는 메서드 동작에 대해 알아보자.

다음 예제는 ChannelHandlerContext에서 Channel에 대한 참조를 얻은 다음, 해당 Channel에서 write()를 호출해 이벤트가 파이프라인 전체를 통과하게 한다.

ChannelHandlerContext ctx = ...;
Channel channel = ctx.channel();
channel.write(Unpooled.copiedBuffer("Netty in Action", CharsetUtil.UTF_8));

다음 예제도 비슷하지만 이번에는 ChannelPipeline을 통해 기록한다.

ChannelHandlerContext ctx = ...;
ChannelPipeline pipeline = ctx.pipeline();
pipeline.write(Unpooled.copiedBuffer("Netty in Action", CharsetUtil.UTF_8));

Channel 또는 ChannelPipeline에서 호출된 write() 메서드는 파이프라인을 통해 끝까지 전파되는 점은 같지만,

한 핸들러에서 다음 ChannelHandler단계로 전파하는 일은 ChannelHandlerContext가 한다는 점이 다르다.

ChannelPipeline의 특정 지점에서 이벤트 전파를 시작하는 이유가 뭘까?
- 관련이 없는 ChannelHandler를 통과하면서 생기는 오버헤드를 줄일 수 있다.
- 이벤트와 관련된 핸들러에서 이벤트가 처리되는 것을 방지할 수 있다.

ChannelHandlerContext의 write() 호출의 예를 보자.

ChannelHandlerContext ctx = ...;
ctx.write(Unpooled.copiedBuffer("Netty in Action", CharsetUtil.UTF_8));

정리

Channel 하나당 ChannelPipeline 1개가 자동 할당된다.
Pipeline안에는 여러 ChannelHandler로 구성된다.
Channel, ChannelPipeline 메소드와 ChannelHandlerContext 메서드 적용의 차이점
Channel, ChannelPipeline, ChannelHandlerContext의 다양한 메서드

출처 : 네티인 액션

https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

book.naver.com

[Springboot/Gradle] JAVA SMTP로 비밀번호 찾기 메일 보내기(NAVER)

코딩하는 너구리 — Sun, 3 Jan 2021 02:10:32 +0900

간단한 서비스를 개발하다가 회원들의 비밀번호 찾기 기능이 필요하게 되었고,

이메일 정보를 이용해 해당 기능을 구현하기로 결정하였습니다.

JAVA SMTP가 잘 되어 있어서 어렵지 않게 구현할 수 있었으며 복잡한 내용은 아니므로 중간중간 사진을 첨부해 참고하기 편하도록 글을 남겨두려 합니다.

SMTP란?

간이 전자 우편 전송 프로토콜(Simple Mail Transfer Protocol, SMTP)은 인터넷에서 이메일을 보내기 위해 이용되는 프로토콜이다. 메일 서버간의 송수신뿐만 아니라, 메일 클라이언트에서 메일 서버로 메일을 보낼 때에도 사용되는 경우가 많다. (출처 : 위키피디아 )

간단히 Simple Mail Transfer Protocol의 약어로 이메일을 전송하기 위해서 사용되는 정도로만 기억해두고 시작하겠습니다.

개발 환경 - [NAVER] Springboot - Gradle

우선 기본 개발환경은 Springboot와 Gradle입니다.

Maven환경이어도 크게 다를 건 없지만 라이브러리를 셋팅하는 부분이 조금 다르니 그 부분은 잘 해결해주시길...

Gmail이나 nate, daum 등 여러 메일이 있지만 사람들이 가장 많이 사용하는 NAVER를 선택하게 되었습니다.

[의존성 설정] build.gradle에 의존성 설정하기

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-mail'
}

build.gradle에 이렇게 한 줄 적어주시고 [Ctrl + Shift + O] 눌러서 의존성 설정해주시면 됩니다.

[발신자 메일 정보 설정] application.yml에 NAVER 메일 정보 설정하기

SMTP를 통해 메일을 발신할 때, 발신자 메일 정보가 필요합니다. 이를 위해 제 NAVER 사용 정보를 application.yml에 지정해두겠습니다.

spring:
  mail:
    host: smtp.naver.com
    port: 465
    username: 이메일@naver.com
    password: 비밀번호
    properties:
      mail.smtp.auth: true
      mail.smtp.ssl.enable: true

username에 메일 주소를, password의 비밀번호를 설정해주시면 됩니다. 실제 메일의 ID와 PWD를 입력해야 하니, Git에 커밋하실 때에는 꼭 application.yml을 .gitignore 파일을 통해 계정 정보가 노출되지 않도록 조심하세요!

[NAVER 설정] SMTP 사용 설정

다음으로 NAVER 계정을 통해 SMTP를 이용하기 위해서, NAVER 계정에 간단한 설정을 해보도록 하겠습니다.

NAVER 메일에서 위 사진에 보이는 것처럼 톱니바퀴 모양을 눌러주세요.

내용을 확인해본 뒤, 확인 버튼을 눌러 설정을 저장합니다.

이렇게 하면 설정 부분은 모두 끝나게 됩니다.

그럼 이제 코드에서 실제 메일을 보내보도록 하겠습니다.

[코드 구현]

이제 Controller에 "비밀번호 찾기" API를 만들어보도록 하겠습니다.

먼저 메일 전송을 위해 JavaMailSender를 받아오겠습니다.

일반적으로 @Autowired 어노테이션을 이용하지만, 어노테이션을 선언하지 않은 이유는

저는 UserController에 @RequiredArgsConstructor 어노테이션을 활용하여 @Autowired는 사용하지 않았습니다.

위 사진처럼 javaMailSender를 선언해주면 이후 코드에서 사용할 수 있습니다.

이전에 build.gradle에서 설정해주었기 때문에 바로 불러올 수 있는 것을 확인할 수 있습니다.

추가적으로 발신자 메일 주소인 from 값은 application.yml에 설정한 값을 @Value 를 통해 가져왔습니다.

그럼 이제 비밀번호 찾기 API에 적용해보도록 하겠습니다.

우선 MimeMessageHelper를 이용하였습니다.

비밀번호 찾기 안내 메일에서 이미지까지 첨부하고 싶었기 때문에 선택하게 되었고

생각보다 사용하기 편하게 메서드가 잘 정의되어 있었기 때문입니다.

setFrom(발신자 메일 주소), setTo(수신인 주소), setSubject(제목), setText(메일 내용) 등

메서드 이름만으로도 용도를 이해하기 쉽게 만들어져 있습니다.

메일의 본문 내용은 mailBodyUtil.getMailBody() 함수를 직접 정의하였습니다.

함수는 String 형태로 HTML 코드를 리턴하도록 하였습니다.

중간에 사용한 addInline() 메서드는 본문에 첨부한 이미지를 위해 사용하였습니다.

"hago" 라는 이름으로, 본문에서 <img src=\"cid:hago\"> 형태의 HTML을 작성하였기 때문에

이미지에 해당하는 파일을 FileDataSource()를 통해 첨부해주는 방식입니다.

일반적으로 데스크톱에서 테스트 하신다면 FileDataSource("c:\...") 주소로 파일을 설정해주세요

값을 다 설정해준 뒤에는 javaSender.send()를 이용하여 발송해주었습니다.

최종적으로 발송에 성공한 사진을 첨부해두겠습니다.

Netty ByteBuf - 바이트 버퍼

코딩하는 너구리 — Tue, 29 Dec 2020 17:08:56 +0900

앞서 언급한 것처럼 네트워크 데이터의 기본 단위는 항상 바이트이다.

자바 NIO는 ByteBuffer라는 자체 바이트 컨테이너를 제공하지만 이 클래스는 사용법이 너무 복잡해 사용하기 부담스럽다.

네티에는 네트워크 개발자에게 더 나은 API를 제공하는 강력한 구현인 ByteBuf가 있다.

네티는 데이터 처리를 위한 API를 ByteBuf 추상 클래스와 ByteBufHolder 인터페이스라는 두 컴포넌트를 통해 노출한다.

ByteBuf API의 장점은 다음과 같다.

사용자 정의 버퍼 형식으로 확장할 수 있음
내장 복합 버퍼 형식을 통해 투명한 제로 카피를 달성할 수 있음.
용량을 필요에 따라 확장할 수 있음(JDK의 StringBuilder와 비슷)
ByteBuffer의 flip() 메서드 호출 없이도 리더와 라이터 모드 전환이 가능함
읽기와 쓰기에 고유 인덱스를 적용함
메서드 체인이 지원됨
참조 카운팅이 지원됨
풀링이 지원됨

ByteBuf

모든 네트워크 통신은 직접 다루기 까다로운 바이트 시퀀스를 주고받는 방식으로 이뤄지므로 효율적이고 사용하기 쉬운 데이터 구조가 반드시 필요하다. ByteBuf에 대해 알아보자.

작동 방식

ByteBuf는 읽기와 쓰기를 위한 고유한 두 인덱스를 유지한다. ByteBuf에서 데이터를 읽으면 ByteBuf의 readerIndex가 읽은 바이트 수만큼 증가한다. 비슷하게 데이터를 기록하면 writerIndex가 증가한다.

ByteBuf 메서드 중 이름이 read나 write로 시작하는 메서드는 해당 인덱스를 증가시키지만,

이름이 set이나 get으로 시작하는 메서드는 인덱스를 증가시키지 않으며, 메서드의 인수로 전달한 인덱스를 기준으로 작업한다.

사용 패턴

네티를 사용하는 동안 ByteBuf의 몇 가지 공통적인 사용 패턴을 접하게 된다. 세 가지의 사용 패턴에 대해 알아보자.

힙 버퍼

보조 배열이라고 하는 가장 자주 이용되는 ByteBuf 패턴이며, JVM의 힙 공간에 데이터를 저장한다. 이 패턴은 풀링이 사용되지 않는 경우 빠른 할당과 해제 속도를 보여준다.

ByteBuf heapBuf = ...;
if (heapBuf.hasArray()) {    // ByteBuf에 배열이 있는지 확인
    byte[] array = heapBuf.array();    // 있는 경우 배열의 참조를 얻음
    int offset = heapBuf.arrayOffset() + heapBuf.readerIndex();    // 첫 번째 바이트에 대한 오프셋을 계산
    int length = heapBuf.readableBytes();    // 읽을 수 있는 바이트를 얻음
    handleArray(array, offset, length);    // 배열, 오프셋, 길이를 매개변수로 지정하고 메서드를 호출
}

다이렉트 버퍼

ByteBuf의 Javadoc을 보면 "다이렉트 버퍼의 내용은 일반적인 가비지 컬렉션이 적용되는 힙 바깥에 위치한다"라고 명시되어 있다. 다이렉트 버퍼가 네트워크 데이터 전송에 이상적이기 때문이다. 데이터가 힙 할당 버퍼에 있는 경우 JVM은 소켓을 통해 전송하기 전에 내부적으로 버퍼를 다이렉트 버퍼로 복사해야 한다.

다이렉트 버퍼의 주요 단점은 힙 기반 버퍼보다 할당과 해제의 비용 부담이 약간 더 크다는 것이다. 또한 레거시 코드를 이용하는 경우 다른 단점을 경험할 수 있는데, 데이터가 힙에 있지 않기 때문에 다음 예제에 나오는 것처럼 복사본을 만들어야 한다.

ByteBuf directBuf = ...;
if (!directBuf.hasArray()) {    // ByteBuf에 보조 배열이 있는 중 확인, 없는 경우 다이렉트 버퍼임
    int length = directBUf.readableBytes();
    byte[] array = new byte[length];
    directBuf.getBytes(directBuf.readerIndex(), array);    // 바이트를 배열로 복사
    handleArray(array, 0, length);
}

복합 버퍼

세 번째이자 마지막 패턴은 복합 버퍼이다. 이 패턴에서는 ByteBuf 인스턴스를 필요에 따라 추가 및 삭제할 수 있다.

헤더와 본문의 두 부분으로 구성되는 메시지를 HTTP를 통해 전송하는 경우를 예로 들어보자. 두 부분은 애플리케이션의 각기 다른 모듈에서 생성되며, 메시지를 전송할 때 조립된다. 애플리케이션에는 동일한 메시지 본문을 여러 메시지에 재사용하는 옵션이 있으며, 이 옵션을 이용하는 경우 각 메시지에 새로운 헤더가 생성된다.

CompositeByteBuf를 이용하면 메시지마다 두 버퍼를 다시 할당할 필요가 없어 아주 편리하며, 공통 ByteBuf API를 노출할 때 불필요하게 복사할 필요가 없게 해준다.

CompositeByteBuf messageBuf = Unpooled.compositeBuffer();
ByteBuf headerBuf = ...;
ByteBuf bodyBuf = ...;
messageBuf.addComponents(headerBuf, bodyBuf);
...
messageBuf.removeComponent(0);    // 헤더를 제거
for (ByteBuf buf : messageBuf) {
    System.out.println(buf.toString());
}

ByteBuf 메소드

ByteBuf buffer = ...;

buffer.capacity()    // ByteBuf 인덱스는 [ 0 ~ capacity()-1 ]

buffer.discardReadBytes();    // 이미 읽은 바이트 공간 회수, 메모리 복사로 자주 사용하는건 좋지 않음

buffer.readByte();    // buffer에서 Byte를 읽음

buffer.isReadable();    // 읽을 수 있는 바이트가 있는지 확인

buffer.writableBytes();    // 버퍼에 공간이 충분한지 확인
// ex -> while(buffer.writableBytes() >= 4) ...

buffer.writeBytes(data);        // buffer에 data 내용을 씀

readerIndex, writerIndex 인덱스 관리

// 인덱스를 지정한 위치로 이동하려면 readerIndex(int)나 writerIndex(int)를 호출하면 된다.

// clear()를 호출하면 readerIndex와 writerIndex를 모두 0으로 설정할 수 있다.

// clear()는 메모리를 복사하지 않으므로 discardReadBytes()보다 훨씬 비용이 낮다.

// indexOf(val) 지정한 값의 인덱스를 알아낸다.

// forEachByte(ByteBufProcessor.FIND_NUL)    NULL을 찾아낸다.
// forEachByte(ByteBufProcessor.FIND_CR)    리턴문자(\n)를 찾아낸다.

파생 버퍼

파생 버퍼는 ByteBuf의 내용을 특수한 방법으로 나타내는 뷰를 제공한다. 파생 버퍼의 종류는 다음과 같다.

duplicate()
slice()
slice(int, int)
Unpooled.unmodifiableBuffer(...)
order(ByteOrder)
readSlice(int)

파생 버퍼는 생성하는 비용은 낮지만 파생 버퍼의 내용을 수정하면 원본 인스턴스까지 수정된다는 데 주의해야 한다.

ByteBuf 복사

기존 버퍼의 복사본이 필요하면 copy()나 copy(int, int)를 이용하면 된다. 파생버퍼와 달리 이 메서드에서 반환하는 ByteBuf는 데이터의 독립된 복사본이다.

출처 : 네티인 액션

https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

book.naver.com

Netty 전송 API

코딩하는 너구리 — Mon, 28 Dec 2020 23:07:04 +0900

Ch04. 전송 API

네트워크를 통해 전송되는 데이터는 모두 바이트 형식이다.

네티는 모든 전송 구현에 공통 API를 기반 레이어로 활용하므로 JDK를 직접 이용할 때보다 블로킹-논블로킹 변환 작업이 훨씬 간단하게 이루어진다.

코드가 구현 세부사항으로 오염될 우려가 적고, 전체 코드 기반을 광범위하게 리팩터링할 필요가 없다.

연결을 수락한 다음, 클라이언트로 "Hi!" 라는 메시지를 전송한 뒤 연결을 닫는 간단한 애플리케이션을 작성해보자.

NettyNioServer

import io.netty.bootstrap.ServerBootstrap;
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.*;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.util.CharsetUtil;

import java.net.InetSocketAddress;
import java.nio.charset.Charset;

public class NettyNioServer {
    public static void main(String[] args) throws Exception{
        int port = 8888;
        final ByteBuf buf = Unpooled.copiedBuffer("Hi! \n", Charset.forName("UTF-8"));
        EventLoopGroup group = new NioEventLoopGroup();    // 논블로킹 모드를 위해 NioEventGroup을 이용
        try {
            ServerBootstrap b = new ServerBootstrap();    // ServerBootstrap 생성
            b.group(group).channel(NioServerSocketChannel.class)
                    .localAddress(new InetSocketAddress(port))
                    .childHandler(new ChannelInitializer<SocketChannel>() {    // 연결이 수락될 때마다 호출될 ChannelInitializer를 지정
                        @Override
                        public void initChannel(SocketChannel ch) throws Exception {
                            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){    // 이벤트를 수신하고 처리할 ChannelInboundHandlerAdapter를 추가
                                @Override
                                public void channelActive(ChannelHandlerContext ctx) throws Exception {
                                    ctx.writeAndFlush(buf.duplicate())
                                        .addListener(ChannelFutureListener.CLOSE);
                                }
                            });
                        }
                    });
            ChannelFuture f = b.bind().sync();
            f.channel().closeFuture().sync();
        } finally {
            group.shutdownGracefully();
        }
    }
}

일반적으로 Netty를 사용하지 않은 구현에 비해 가독성이 높고, 간편하다는 것을 알 수 있다.

모든 구현들이 Channel, ChannelPipeline, ChannelHandler를 기준으로 정의되고 있음을 기억해두자.

Channel 인터페이스는 모든 입출력 작업에 이용되므로 전송 API의 핵심이라고 볼 수 있다.

Channel에는 ChannelPipeline과 ChannelConfig 등이 할당되는데,

ChannelConfig는 Channel에 대한 모든 구성 설정을 포함하며, 임시 변경(hot change)을 지원한다.

또, Channel은 고유하므로 정렬 순서를 보장하기 위해 java.lang.Comparable을 이용한다. 즉, 고유한 두 Channel 인스턴스가 동일한 해시코드를 반환하는 경우에는 Error가 발생한다.

ChannelPipeline은 인바운드와 아웃바운드 데이터와 이벤트에 적용될 ChannelHandler 인스턴스를 모두 포함한다.

일반적인 ChannelPipeline의 용도는 다음과 같다.

데이터를 한 포맷에서 다른 포맷으로 변환
예외에 대한 알림 제공
Channel의 활성화 또는 비활성화에 대한 알림 제공
Channel을 EventLoop에 등록할 때 또는 등록 해제할 때 알림 제공
사용자 정의 이벤트에 대한 알림 제공

ChannelHandler 인스턴스를 필요에 따라 추가하거나 제거해 ChannelPipeline을 즉석으로 수정할 수 있으며, 이러한 네티의 특징을 활용하면 아주 유연한 애플리케이션을 개발할 수 있다는 것을 기억하자.

원격 피어로 데이터를 기록하고 플러시하는 일반적인 Channel 작업의 예를 보자.

Channel channel = ...
ByteBuf buf = Unpooled.copiedBuffer("your data", CharsetUtil.UTF_8);
ChannelFuture cf = channel.writeAndFlush(buf);    // 데이터를 기록하고 플러시
cf.addListerner(new ChannelFutureListener(){    // 기록이 완료되면 알림을 받을 ChannelFutureListener를 추가
    @Override
    public void operationComplete(ChannelFuture future) {
        if(future.isSuccess()){    // 기록이 완료될 경우
            System.out.println("Write success!");
        } else {
            System.out.println("Write error");    // 오류를 로깅
            future.cause().printStacktrace();
        }
    }
})

네티의 Channel 구현은 스레드에 대해 안전하므로 여러 스레드를 이용하는 경우에도 Channel의 참조를 저장하고 원격 피어에 뭔가를 출력할 때 이용할 수 있다. 다음 예제에는 여러 스레드로 기록을 수행하는 간단한 예를 보자.

Channel channel = ...
ByteBuf buf = Unpooled.copiedBuffer("your data", CharsetUtil.UTF_8).retain();
Runnable writer = new Runnable() {    // 데이터를 채널로 기록하는 Runnable 생성
    @Override
    public void run() {
        channel.write(buf.duplicate());
    }
};

Executor executor = Executors.newCachedThreadPool();    //  스레드풀 Executor에 대한 참조를 얻음

// 한 스레드에 기록
executor.execute(writer);

// 다른 스레드에 기록
executor.execute(writer);

...

NIO

NIO는 모든 입출력 작업의 완전한 비동기 구현을 제공하며 셀렉터 기반 API를 활용한다.

셀렉터의 기본 개념은 Channel의 상태가 변경되면 요청이 알림을 받을 수 있는 레지스트리 역할을 하는 것이다.

지원되는 상태 변경은 다음과 같다.

새로운 Channel이 수락되고 준비됨.
Channel 연결이 완료됨
Channel에 읽을 데이터가 있음
Channel을 이용해 데이터를 기록할 수 있음

애플리케이션이 상태 변경에 반응한 후에는 셀렉터가 재설정되며 해당 스레드에서 변경을 검사하고 적절하게 반응하는 프로세스가 반복된다.

논블로킹 코드 기반의 환경에서..

코드 기반에 블로킹 호출이 없거나 블로킹 호출을 제한할 수 있다면 NIO 또는 epoll(리눅스의 경우)을 이용하는 것이 좋다. 다수의 동시 연결을 처리하기 위한 것이지만 동시 연결이 많지 않은 경우에도 아주 잘 작동한다. 특히 여러 연결에 스레드를 공유할 수 있다는 것이 장점이다.

출처 : 네티인 액션

https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

book.naver.com

Netty 컴포넌트와 설계

코딩하는 너구리 — Thu, 10 Dec 2020 11:10:33 +0900

Channel, EventLoop, ChannelFuture

이제 네티의 네트워킹 추상화를 대표한다고 말할 수 있는 Channel, EventLoop, ChannelFuture 클래스를 더 자세히 알아보자. 이 세 가지 개념의 기능들을 다음과 같이 요약해볼 수 있다.

Channel : 소켓(Socket)
EventLoop : 제어 흐름, 멀티스레딩, 동시성 제어
ChannelFuture : 비동기 알림

Channel 인터페이스

자바 기반 네트워크에서 기본 구조는 Socket 클래스다. 네티의 Channel 인터페이스는 Socket으로 직접 작업할 때의 복잡성을 크게 완화하는 API를 제공한다.

ex) EmbeddedChannel, LocalServerChannel, NioDatagramChannel, NioSctpChannel, NioSocketChannel...

EventLoop 인터페이스

EventLoop는 연결의 수명주기 중 발생하는 이벤트를 처리하는 네티의 핵심 추상화를 정의한다.

다음 그림은 Channel, EventLoop, EventLoopGroup 간의 관계를 개략적으로 보여준다.

이러한 관계를 정리하면 다음과 같다.

EventLoopGroup은 하나 이상의 EventLoop를 포함한다.
EventLoopGroup은 Channel에 EventLoop를 할당
EventLoop는 수명주기 동안 하나의 Thread로 바인딩된다.
EventLoop에서 처리되는 모든 입출력 이벤트는 해당 전용 Thread에서 처리된다.
하나의 Channel은 수명주기 동안 하나의 EventLoop에 등록할 수 있다.
EventLoop를 하나 이상의 Channel로 할당할 수 있다.

ChannelFuture 인터페이스

이전에 설명했듯이 네티의 모든 입출력 작업은 비동기적이다. 즉, 작업이 즉시 반환되지 않을 수 있으므로 나중에 결과를 확인하는 방법이 필요하다. 이를 위해 네티는 ChannelFuture를 제공하며, 이 인터페이스의 addListener() 메서드는 작업이 완료되면 알림을 받을 ChannelFutureListener 하나를 등록한다.

ChannelFuture는 미래에 실행될 작업의 결과를 위한 표시자라고 생각할 수 있다. 실행되는 시점은 여러 요소에 의해 좌우되므로 정확한 시점을 예측하기는 불가능하지만 실행된다는 점은 확실하다. 또한 동일한 Channel에 속하는 모든 작업은 호출된 순서와 동일한 순서로 실행된다.

ChannelHandler 인터페이스

개발자의 관점에서 네티의 핵심 컴포넌트는 인바운드와 아웃바운드 데이터의 처리에 적용되는 모든 애플리케이션 논리의 컨테이너 역할을 하는 ChannelHandler이다.

이런게 가능한 이유는 ChannelHandler의 메서드가 네트워크 이벤트에 의해 트리거되기 때문이다.

실제로 ChennelHandler는 데이터를 변환하거나 예외를 처리하는 등 거의 모든 종류의 작업에 활용할 수 있다.

ChannelPipeline 인터페이스

ChannelPipeline은 ChannelHandler 체인을 위한 컨테이너를 제공하며, 체인 상에서 인바운드와 아웃바운드 이벤트를 전파하는 API를 정의한다.

Channel이 생성되면 여기에 자동으로 자체적인 ChannelPipeline이 할당된다. ChannelHandler는 다음과 같이 ChannelPipeline 안에 설치된다.

ChannelInitializer 구현은 ServerBootstrap에 등록된다.
ChannelInitializer.initChannel()이 호출되면 ChannelInitializer가 ChannelPipeline과 ChannelHandler의 커스텀 집합을 파이프라인에 설치한다.
ChannelInitializer는 ChannelPipeline에서 자신을 제거한다.

데이터를 전송하거나 수신할 때 어떤 일이 일어나는지 확인하면서 ChannelHandler와 ChannelPipeline간의 관계를 더 자세히 알아보자.

ChannelHandler는 ChannelPipeline을 통해 오가는 이벤트를 처리 코드를 위한 범용 컨테이너라고 할 수 있다.

파이프라인을 통해 이벤트를 이동시키는 역할은 Channelhandler가 담당한다.

이벤트를 수신하고, 구현된 처리 논리를 실행하며 체인 상의 다음 핸들러로 데이터를 전달한다.

핸들러가 실행되는 순서는 추가된 순서에 의해 결정된다.

ChannelPipeline이라고 말할 때는 이러한 Channelhandler의 정렬된 배치 전체를 의미한다고 보면 된다.

클라이언트의 관점에서 서버로 움직이는 이벤트는 아웃바운드이며, 그 반대는 인바운드다.

그림을 보면 인바운드와 아웃바운드 이벤트를 동일한 파이프라인에 설치할 수 있음을 알 수 있다. 메시지나 다른 인바운드 이벤트를 읽을 때는 파이프라인의 앞쪽에서 시작하며 첫 번째 ChannelInboundHandler로 전달된다. 데이터를 처리한 후에는 다음 ChannelInboundHandler로 데이터를 전달한다. 최종적으로 파이프라인의 뒤쪽에 이르면 모든 처리가 종료된다.

데이터의 아웃바운드 이동 역시 개념상 동일하며 ChannelOutboundHandler가 뒤쪽에서 시작해 앞쪽까지 이를 때까지 이동한다. 이 지점에서 아웃바운드 데이터는 그림에 Socket으로 나오는 네트워크 전송에 도달한다. 보통은 이때 쓰기 작업이 트리거된다.

인코더와 디코더

Netty로 메시지를 전송하거나 수신할 때는 데이터를 변환해야 한다.

인바운드 메시지는 바이트에서 다른 포맷(보통 자바 객체)으로 변환되는 디코딩을 거친다.

아웃바운드 메시지는 반대로 현재 포맷에서 바이트로 인코딩된다.

이러한 두 가지 변환이 필요한 이유는 네트워크 데이터는 반드시 연속된 바이트여야하기 때문이다.

부트스트랩

네티의 부트스트랩 클래스는 프로세스를 지정된 포트로 바인딩(서버 부트스트랩)하거나 프로세스를 지정된 호스트의 지정된 포트에서 실행중인 다른 호스트로 연결(클라이언트 부트스트랩)하는 등의 일을 하는 애플리케이션의 네트워크 레이어를 구성하는 컨테이너를 제공한다.

서버 부트스트랩은 ServerBootstrap을 이용하고 클라이언트 부트스트랩은 Bootstrap을 이용한다.

클라이언트를 부트스트랩할 때는 EventLoopGroup 하나가 필요하지만 서버는 두 개가 필요하다.

서버는 각기 다른 Channel의 두 집합을 필요로 한다.

첫 번째 집합은 로컬 포트로 바인딩된 서버 자체의 소켓을 나타내는 ServerChannel

두 번째 집합은 서버가 수락한 연결마다 하나씩 들어오는 클라이언트 연결을 처리하기 위해 생성된 모든 Channel

정리

Channel: 자바 기반 네트워크에서 기본 입출력 작업을 하며 소켓(Socket)으로 작업할 때의 복잡성을 완화시켜주는 API

Socket 통신에서 Socket 정도로 생각해두자.

ChannelFuture: 비동기 작업에서 알림 기능을 함. 특정 시점에 할 행동들을 정의할 수 있음

( ex_채널이 연결되면 인증과정을 해라.)

이전에 설명한 것처럼 약속된 미래의 시점으로 생각해두자.(채널 연결됨, 채널 연결 끊어짐 등..)

ChannelPipeLine: ChannelHandler 체인을 위한 컨테이너 역할. 채널이 생성되면 ChanelPipeline은 자동으로 할당된다.

Channel에 할당된 InboundHandler, OutboundHandler 등 이벤트들이 Channel 내에서 움직이는 통로 정도로 생각하자.

ChannelHandler : 이벤트 수신, 구현된 이벤트 논리 실행, 다음 핸들러로 데이터 전달 등 모든 애플리케이션 논리의 컨테이너 역할을 함.

Channel 통로를 타고 이동하는 이벤트들.

ex ) 나는 서버에 채널이 연결되면 "Hello" 라고 보내야지

-> ChannelInboundHandler에서 channelActive() 메소드에 "Hello" 를 전송하도록 설정.

EventLoopGroup : EventLoop들을 포함하는Group

EventLoop : 수명 주기동안 하나의 쓰레드로 바인딩되며 이벤트를 관리하여 제어흐름, 멀티스레딩, 동시성 제어 등의 기능을 수행할 수 있음

Channel과 연결할 이벤트 묶음으로 생각해두자. Handler로 정의된 이벤트들의 묶음 말이다.

Channel당 하나의 EventLoop로 할당되므로 내가 (서버 또는 클라이언트에) 할당해줄 이벤트의 묶음을 EventLoop에 모아서 Channel에 할당해줄꺼야!

네트워크 데이터는 연속된 바이트여야 하기 때문에 인코더와 디코더의 개념이 필요하다.

(JAVA) 내가 보낼 데이터 -> (인코딩) -> (Byte) 데이터 전송 완료
인코더 : 아웃바운드 메시지는 현재 포맷에서 바이트로 인코딩하는 과정을 거치는데, 이 과정을 인코더가 수행

(Byte) 내가 받을 데이터 -> (디코딩) -> (JAVA) 데이터 수신 완료
디코더 : 인바운드 메시지의 경우 바이트에서 다른 포맷(보통 자바 객체)로 변환하는 디코딩 과정을 거치는데, 이 과정을 디코더가 수행

부트스트랩
서버 vs 클라이언트

서버를 지정된 포트로 바인딩할 서버 부트스트랩과,

지정된 호스트의 지정된 포트에서 실행중인 호스트로 연결하는 클라이언트 부트스트랩이 있다는 정도만 알고 넘어가자.

출처 : 네티인 액션

https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

book.naver.com

Java Netty 에코 서버-클라이언트 구현하기

코딩하는 너구리 — Wed, 9 Dec 2020 18:39:42 +0900

Echo 서버 만들기

모든 네티 서버에는 다음 항목이 필요하다.

하나 이상의 ChannelHandler : 이 컴포넌트는 클라이언트로부터 받은 데이터를 서버측에서 처리하는 비즈니스 논리를 구현한다.
부트스트랩 : 서버를 구성하는 시동 코드를 의미한다. 최소한 서버가 연결 요청을 수신하는 포트 서버와 바인딩하는 코드가 있어야 한다.

ChannelHandler와 비즈니스 논리

Echo 서버는 들어오는 메시지에 반응해야 하므로 인바운드 이벤트에 반응하는 메서드가 정의된 ChannelInboundHandler 인터페이스를 구현해야 한다.

관심을 가질 메서드는 다음과 같다.

channelRead() : 메시지가 들어올 때마다 호출된다.
channelReadComplete() : channelRead()의 마지막 호출에서 현재 일괄 처리의 마지막 메시지를 처리했음을 핸들러에 통보한다.
exceptionCaught() : 읽기 작업 중 예외가 발생하면 호출된다.

EchoServerHandler

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelFutureListener;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.util.CharsetUtil;

@ChannelHandler.Sharable
public class EchoServerHandler extends ChannelInboundHandlerAdapter {

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        ByteBuf in = (ByteBuf)msg;
        System.out.println("Server received : " + in.toString(CharsetUtil.UTF_8));
        ctx.write(in); // 받은 메시지를 발신자에게로 Echo 시킨다.
    }

    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
        System.out.println("Bye");
        ctx.writeAndFlush(Unpooled.EMPTY_BUFFER) // 대기중인 메시지를 플러시하고 채널을 닫음
                .addListener(ChannelFutureListener.CLOSE);
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        cause.printStackTrace();
        ctx.close();	// 채널 닫기
    }
}

ServerHandler 코드를 작성하면서 기억해둘 점은 다음과 같다.

ChannelHandler는 네 가지 이벤트 유형에 의해 호출된다.
애플리케이션은 ChannelHandler를 구현하거나 확장해 이벤트 수명주기를 후크하고 커스텀 애플리케이션 논리를 제공한다.

서버 부트스트랩

지금까지 EchoServerHandler가 구현하는 핵심 비즈니스 논리를 살펴봤다. 이제 다음 과정을 포함하는 서버의 부트스트랩을 진행해야 한다.

서버가 수신할 포트를 바인딩하고 들어오는 연결 요청을 수락한다.
EchoServerHandler 인스턴스에 인바운드 메시지에 대해 알리도록 Channel을 구성한다.

EchoServer 클래스

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;

import java.net.InetSocketAddress;

public class EchoServer {
    private final int port;

    public EchoServer() {
        this.port = 8888;
    }

    public static void main(String[] args) throws Exception {
        new EchoServer().start();   // 서버의 start() 메소드 호출
    }

    private void start() throws Exception {
        final EchoServerHandler serverHandler = new EchoServerHandler();
        EventLoopGroup group = new NioEventLoopGroup(); // EventLoopGroup 생성
        try {
            ServerBootstrap b = new ServerBootstrap();  // ServerBootstrap 생성
            b.group(group)
                    .channel(NioServerSocketChannel.class)  // NIO 전송채널을 이용하도록 지정
                    .localAddress(new InetSocketAddress(port))  // 지정된 포트로 소켓 주소 설정
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) throws Exception { // EchoServerHandler 하나를 채널의 Channel Pipeline 으로 추가
                            ch.pipeline().addLast(serverHandler);
                        }
                    });
            ChannelFuture f = b.bind().sync();  // 서버를 비동기식으로 바인딩
            f.channel().closeFuture().sync();   // 채널의 CloseFuture를 얻고 완료될 때까지 현재 스레드를 블로킹
        } finally {
            group.shutdownGracefully().sync();  // EventLoopGroup을 종료하고 모든 리소스 해제
        }
    }
}

지금 완성한 서버 구현에서 중요한 단계를 검토해보자.

EchoServerHandler는 비즈니스 논리를 구현한다.
main() 메서드는 서버를 부트스트랩한다.

부트스트랩에는 다음 단계가 필요하다.

서버를 부트스트랩하고 바인딩하는 데 이용할 ServerBootstrap 인스턴스를 생성한다.
새로운 연결 수락 및 데이터 읽기/쓰기와 같은 이벤트 처리를 수행할 NioEventLoopGroup 인스턴스를 생성하고 할당한다.
서버가 바인딩하는 로컬 InetSocketAddress를 지정한다.
EchoServerHandler 인스턴스를 이용해 새로운 각 Channel을 초기화한다.
ServerBootstrap.bind()를 호출해 서버를 바인딩한다.

Echo 클라이언트 만들기

Echo 클라이언트는 다음과 같은 일을 한다.

서버로 연결한다.
메시지를 하나 이상 전송한다.
메시지마다 대기하고 서버로부터 동일한 메시지를 수신한다.
연결을 닫는다.

ChannelHandler를 이용한 클라이언트 논리 구현

channelActive() : 서버에 대한 연결이 만들어지면 호출된다.
chanelRead0() : 서버로부터 메시지를 수신하면 호출된다.
exceptionCaught() : 처리 중에 예외가 발생하면 호출된다.

이제 클라이언트의 ChannelHandler를 만들어 보자.

EchoClientHandler

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.SimpleChannelInboundHandler;
import io.netty.util.CharsetUtil;

@ChannelHandler.Sharable
public class EchoClientHandler extends SimpleChannelInboundHandler<ByteBuf> {

    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        ctx.writeAndFlush(Unpooled.copiedBuffer("Netty Connect()", CharsetUtil.UTF_8)); // 채널 활성화 시 메시지 전송
    }

    @Override
    public void channelRead0(ChannelHandlerContext ctx, ByteBuf msg) throws Exception {
        System.out.println("Client receive : " + msg.toString(CharsetUtil.UTF_8));  // 수신한 메시지 로깅
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        cause.printStackTrace();    // 예외 시 오류를 로깅하고 채널 닫기
        ctx.close();
    }
}

우선 연결이 만들어지면 호출되는 ChannelActive()를 재정의했다.

이 예제에서는 "Netty Connet()"라는 문자열을 인코딩한 바이트 버퍼를 전송한다.

그런 다음, 데이터를 수신할 때 호출되는 channelRead0() 메서드를 재정의했다.

주의할 점은 서버가 전송한 메시지가 여러 청크로 수신될 수 있다는 점이다. 즉, 서버가 5바이트를 전송할 때 5바이트가 모두 한 번에 수신된다는 보장이 없다. 다만 TCP는 스트림 기반 프로토콜이므로 서버가 보낸 순서대로 바이트를 수신할 수 있게 보장한다.

EchoClient

import io.netty.bootstrap.Bootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;

import java.net.InetSocketAddress;

public class EchoClient {
    public EchoClient(){
    }

    public void start() throws Exception {
        EventLoopGroup group = new NioEventLoopGroup();
        try {
            Bootstrap b = new Bootstrap();  // bootstrap 생성
            b.group(group)  // 클라이언트 이벤트 처리할 EventLoopGroup을 지정.
                    .channel(NioSocketChannel.class)    // 채널 유형 NIO 지정
                    .remoteAddress(new InetSocketAddress(8888)) // 서버의 InetSocketAddress를 설정
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        public void initChannel(SocketChannel ch) throws Exception {    // 채널이 생성될 때 파이프라인에 EchoClientHandler 하나를 추가
                            ch.pipeline().addLast(new EchoClientHandler());
                        }
                    });
            ChannelFuture f = b.connect().sync();   // 원격 피어로 연결하고 연결이 완료되기를 기다림
            f.channel().closeFuture().sync();   // 채널이 닫힐 때까지 블로킹함.
        } finally {
            group.shutdownGracefully().sync();  // 스레드 풀을 종료하고 모든 리소스를 해제함
        }
    }

    public static void main(String[] args) throws Exception {
        new EchoClient().start();
    }
}

Client 과정 정리

클라이언트를 초기화하기 위한 Bootstrap 인스턴스를 생성한다.

새로운 연결을 생성하고 인바운드와 아웃바운드 데이터를 처리하는 것을 포함하는 이벤트 처리를 제어할 NioEventLoopGroup 인스턴스를 만들고 할당한다.

서버로 연결하기 위한 InetSocketAddress를 생성한다.

연결이 만들어지면 파이프라인에 EchoClientHandler 하나를 추가한다.

모든 준비가 완료되면 Bootstrap.connect()를 호출해 원격 서버로 연결한다.

빌드 및 실행

빌드 및 실행을 위해서는 Netty를 먼저 다운받아야 한다. 다운 받은 뒤, 프로젝트에 외부 라이브러리에 Netty를 추가해주면 된다.

netty.io/

Netty: Home

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty is a NIO client server framework which enables quick and easy development of network applications s

netty.io

이후 소스를 작성하고 Server와 Client를 각각 실행시켜 보자.

IntelliJ 환경에서 실행된 모습

EchoServer

EchoClient

이상으로 JAVA Netty 에코 서버-클라이언트 구현을 마치겠습니다.

정리

@Sharable

: 이 어노테이션이 붙은 클래스의 인스턴스는 여러 Channel에서 공유할 수 있음을 나타낸다.

SimpleChannelInboundHandler와 ChannelInboundHandler 비교

Client에서는 SimpleChannelInboundHandler를 사용했다.

클라이언트에서 channelRead0()이 완료된 시점에서 들어오는 메시지는 이미 확보된 상태이며 메서드가 반환될 때 ByteBuf에 대한 메모리 참조를 해제한다.

반면 서버에서는 ChannelRead()가 반환될 때까지 비동기의 write() 작업이 완료되지 않았을 수 있다. 이 메시지는 channelReadComplete()에서 writeAndFlush()가 호출될 때 해제된다.

이처럼 서로 메모리 해제하는 구간이 다르고, 메서드의 약간의 차이가 있으므로

Client에서는 SimpleChannelInboundHandler를, Server에서는 ChannelInboundHandler를 사용하는 것으로 기억해두고 넘어가자.

참고 : https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

book.naver.com

Netty의 개념과 아키텍처

코딩하는 너구리 — Wed, 9 Dec 2020 10:18:38 +0900

Netty

: 비동기식 이벤트 기반 네트워킹 프레임워크

일반적인 JAVA 블로킹 입출력 예제

ServerSocket serverSocket = new ServerSocket(portNumber);
Socket clientSocket = serverSocket.accept();

BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
PrintWriter out = new PrintWriter(clientSocket.getOutputStream(), true);

String request, response;

while((request = in.readLine)) != null) {
	if ("Done".equals(request))
    	break;
	response = processRequest(request);
    out.println(response);
}

간단한 예제를 하나 살펴보자. 이 예제에서 accept()는 ServerSocket에서 연결될 때까지 진행을 블로킹하며 연결되면 클라이언트와 서버간 통신을 위한 새로운 Socket을 하나 반환한다.

또한 이 코드는 한 번에 한 연결만 처리한다.

기본적인 Socket API의 문제점

위 방식을 살펴보면, 여러 스레드가 입력이나 출력 데이터가 들어오기를 기다리며 무한정 대기 상태에 빠질 수 있다.

- 무한 대기(좀비), 리소스 낭비, 오버헤드 등등..

자바 NIO

위와 같은 문제를 갖는 블로킹 시스템 호출 방식 외에도 네이티브 소켓 라이브러리에는 오래전부터 네트워크 리소스 사용률을 세부적으로 제어할 수 있는 논블로킹 호출이 포함돼 있었다.

* setsockopt()를 이용하면 데이터가 없을 때, 즉 블로킹 호출이라면 진행을 블로킹할 상황에서 읽기/쓰기 호출이 즉시 반환하도록 소켓을 구성할 수 있다.

논블로킹 입출력을 위한 자바 지원 기능은 2002년 JDK 1.4 패키지인 java.nio와 함께 도입됐다.
NIO는 원래 NEW input/output의 약자였지만, 대부분의 사용자는 NIO가 논블로킹 입출력을 나타내며, 블로킹 입출력은 OIO라고 생각한다.

Selector

- 아래 그림의 논블로킹 설계를 보면 이전에 설명한 블로킹 방식의 단점이 사실상 완전히 해결된 것을 알 수 있다.

- 자바의 논블로킹 입출력 구현의 핵심으로서, 논블로킹 Socket의 집합에서 입출력이 가능한 항목을 지정하기 위해 이벤트 통지 API를 이용한다.

언제든지 읽기나 쓰기 작업의 완료 상태를 확인할 수 있으므로 한 스레드로 여러 동시 연결을 처리할 수 있다.

적은 수의 스레드로 더 많은 연결을 처리할 수 있으므로 메모리 관리와 컨텍스트 전환에 따르는 오버헤드가 감소한다.
입출력을 처리하지 않을 때는 스레드를 다른 작업에 활용할 수 있다.

비동기성과 확장성은 어떻게 연결돼 있을까?

먼저 비동기의 개념에 대해 생각해보면 좋을 것 같다. 비동기의 좋은 예시로 이메일이 있다.

보낸 메시지의 답장이 올 수도 있고 답장이 없을 수도 있다. 메시지를 보내는 동안 예기치 않는 메시지를 받을 수도 있다.

또한 비동기 이벤트는 정돈된 관계를 가질 수 있다는 것을 알아두자.

일반적으로 답변은 질문한 사항에 대해서만 받을 수 있고, 답변을 기다리는 동안 다른 일을 할 수도 있다.

비동기성과 확장성은 어떻게 연결돼 있을까?

논블로킹 네트워크 연결은 작업 완료를 기다릴 필요가 없게 해준다. 완전 비동기 입출력은 이 특징을 바탕으로 한 단계 더 나아간다. 비동기 메서드는 즉시 반환하며 작업이 완료되면 직접 또는 나중에 이를 통지한다.

셀렉터는 적은 수의 스레드로 여러 연결에서 이벤트를 모니터링할 수 있게 해준다.

논블로킹 입출력을 이용하면 블로킹 입출력 방식을 이용할 때보다 더 많은 이벤트를 훨씬 빠르고 경제적으로 처리할 수 있다. 이것은 네트워킹 관점에서 우리가 구축하려는 시스템의 핵심이며, 앞으로 알아보겠지만 네티 설계의 핵심이기도 하다.

네티의 핵심 컴포넌트

Channel

하나 이상의 입출력 작업(읽기 또는 쓰기)을 수행할 수 있는 하드웨어 장치, 파일, 네트워크 소켓, 프로그램 컴포넌트와 같은 엔티티에 대한 열린 연결

일단 Channel을 들어오는 데이터와 나가는 데이터를 위한 운송수단이라고 생각하자. Channel은 열거나 닫고, 연결하거나 연결을 끊을 수 있다.

콜백

콜백은 간단히 말해 다른 메서드로 자신에 대한 참조를 제공할 수 있는 메서드다.
콜백은 관심 대상에게 작업 완료를 알리는 가장 일반적인 방법 중 하나다.

네티는 이벤트를 처리할 때 내부적으로 콜백을 이용한다. 콜백이 트리거되면 ChannelHandler 인터페이스의 구현을 통해 이벤트를 처리할 수 있다.

Future

Future는 작업이 완료되면 이를 애플리케이션에 알리는 한 방법이다. 이 객체는 비동기 작업의 결과를 담는 자리표시자 역할을 하며, 미래의 어떤 시점에 작업이 완료되면 그 결과에 접근할 수 있게 해준다.

JDK는 Future를 제공하지만, 수동으로 작업완료 여부를 확인하거나 완료되기 전까지 블로킹하는 기능만 있다. 따라서 네티는 비동기 작업이 실행됐을 때 이용할 수 있는 자체 구현 ChannelFuture를 제공한다.

네티의 모든 아웃바운드 입출력 작업은 ChannelFuture를 반환하며 진행을 블로킹하는 작업은 없다.

앞서 언급한 대로 네티는 기본적으로 비동기식이며 이벤트 기반이다.

ChannelFutureListener를 활용하는 방법을 살펴보자.

먼저 원격 피어로 연결한 다음, connect() 호출로 반환된 ChannelFuture를 이용해 새로운 ChannelFutureListener를 등록한다. 리스너가 연결이 만들어졌다는 알림을 받으면 상태를 확인한다. 작업이 정상적이면 데이터를 Chanel로 기록하며, 그렇지 않으면 ChannelFuture에서 Throwable을 가져온다.

Channel channel = ...;
// 블로킹하지 않음
ChannelFuture future = channel.connect(new InetSocketAddress("192.168.0.1", 25));

future.addListener(new ChannelFutureListener() {
	@Override
    public void operationComplete(ChannelFuture future){
    	if(future.isSuccess()){
        	ByteBuf buffer = Unpooled.copiedBuffer("Hello", Charset.defaultCharset());
            ChannelFuture wf = future.channel().writeAndFlush(buffer);
            ...
        } else {
        	Throwable cause = future.cause();
            cause.printStackTrace();
        }
    }
}

이벤트와 핸들러

네티는 작업의 상태 변화를 알리기 위해 고유한 이벤트를 이용하며, 발생한 이벤트를 기준으로 적절한 동작을 트리거할 수 있다. 다음과 같은 동작이 포함된다.

로깅
데이터 변환
흐름 제어
애플리케이션 논리

네티는 네트워크 프레임워크이므로 이벤트 역시 인바운드 또는 아웃바운드 데이터 흐름에 대한 연관성을 기준으로 분류된다.

인바운드 데이터나 연관된 상태 변화로 트리거되는 이벤트는 다음을 포함한다.

연결 활성화 또는 비활성화
데이터 읽기
사용자 이벤트
오류 이벤트

아웃바운드 이벤트는 다음과 같이 미래에 한 동작을 트리거하는 작업의 결과들이다.

원격 피어로 연결 열기 또는 닫기
소켓으로 데이터 쓰기 또는 플러시

ChannelHandler의 체인을 통한 인바운드와 아웃바운드 이벤트의 흐름

정리

네티의 비동기 프로그래밍 모델은 Future, 콜백의 개념, 그리고 더 깊은 단계에서 이벤트를 핸들러 메서드로 발송하는 작업을 기반으로 작동한다.

작업을 가로채고 인바운드나 아웃바운드 데이터를 즉시 변환하려면 콜백을 제공하거나 작업이 반환하는 Future를 활용하면 간단하다.

또한 셀렉터, 이벤트, 이벤트 루프에 대해 알아두자.

네티는 이벤트를 발생시켜 Selector를 애플리케이션 밖으로 추상화하므로 개발자가 발송 코드를 직접 작성할 필요가 없다. 각 Channel에 해당하는 EventLoop는 내부적으로 모든 이벤트를 처리한다.

- 관심 이벤트 등록

- 이벤트를 ChannelHandler로 발송

- 추가 동작 스케쥴링

EventLoop 자체는 하나의 Channel의 모든 입출력 이벤트를 처리하는 스레드에 의해 제어되며, EventLoop의 수명 기간 동안 달라지지 않는다.

두 유저가 전화를 한다고 가정했을 때, 두 사람 사이에 생긴 전화선을 Channel(채널)로 본다면

왼쪽 유저의 입장에서 오른쪽으로 나가는 이벤트를 아웃바운드 이벤트,

반대로 상대로부터 들어오는 이벤트를 인바운드 이벤트로 볼 수 있다.

또 전화 연결, 전화 끊어짐, 통화중 등 미래에 발생할 수 있는 시점들이며 이를 Future로 볼 수 있고

이러한 이벤트를 알리는 것은 Callback을 통해 이루어진다.

참고 https://book.naver.com/bookdb/book_detail.nhn?bid=10462610

네티 인 액션

book.naver.com

@PostMapping과 @PutMapping의 차이

코딩하는 너구리 — Thu, 15 Oct 2020 09:31:12 +0900

일반적인 형태의 CRUD

개발을 하면서 여느 때처럼 CRUD 코드를 만들고 있었습니다.

@PostMapping과 @PutMapping의 기능이 비슷한데 왜 따로 명시하는지 알고 있나?

질문에 말문이 막혔습니다.

공식처럼 추가/등록은 @PostMapping을 사용하고 수정할 때에는 @PutMapping을 사용했기 때문에 인수인계 혹은 코드 리뷰에 코드를 읽는 사람을 위해 구분지어놓는 줄만 알았습니다.

관련 자료를 찾아보다가 mozilla 사이트의 글을 보고 차이를 조금 이해하게 되었습니다.

developer.mozilla.org/ko/docs/Web/HTTP/Methods/PUT

PUT

HTTP PUT 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체합니다.

developer.mozilla.org

PUT과 POST의 차이는 멱등성으로 설명되어 있습니다.

HTTP 요청에서 멱등성이란 여러 번 연속해서 호출해도 클라이언트가 받는 응답은 동일하다는 것인데 멱등성에 대해 설명된 글을 읽고 차이점을 어느정도 이해하게 된 것 같습니다.

developer.mozilla.org/ko/docs/Glossary/Idempotent

멱등성

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다. 다른 말로는, 멱등성 메�

developer.mozilla.org

처음 관련 정보를 찾기 위해 구글링했을 때, 설명되어 있는 글이 부족하여 포스팅하게 되었습니다.

[ERROR] JSON 순환 참조 문제 해결하기

코딩하는 너구리 — Sat, 19 Sep 2020 06:49:52 +0900

프로젝트를 진행하다가 순환참조 문제가 발생하였다.

에러 메시지는 다음과 같다.

 Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError); nested exception is com.fasterxml.jackson.databind.JsonMappingException: Infinite recursion (StackOverflowError) (through reference chain: com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"]->org.hibernate.collection.internal.PersistentBag[0]->com.mango.harugomin.domain.entity.UserHashtag["user"]->com.mango.harugomin.domain.entity.User["userHashtags"])] with root cause

에러 메시지의 길이가 긴 이유는 순환참조가 발생하였기 때문이다.

Hashtag 기능을 구현하려고 User와 HashTag 테이블이 있고, 양방향 매핑을 풀어주기 위해

User, UserHashtag, HashTag 세 테이블을 이용하였다.

이 상황에서 가운데에 위치한 User_Tag 테이블을 관찰해보자.

User에는 user_hashtag 이름으로 User_Tag 테이블을 담고 있고,

반대로 User_Tag 테이블에서는 user_id로 User를 담고 있었다.

Cycle과 같이 서로를 계속 참조해서 발생하는 순환참조 문제가 발생한 것이다.

해결방법

이러한 문제를 해결하는 방법으로 @JsonIgnore를 사용하는 방법이 있고 @JsonManagedReference와 @JsonBackReference를 사용하는 방법이 있다. 표면적으로 두 방법 모두 순환참조를 방어하는 형태이지만 본질적으로 약간의 차이가 있다. @JsonIgnore의 경우는 실제로 property에 null을 할당하는 방식이고 @JsonManagedReference와 @JsonBackReference는 본질적으로 순환참조를 방어하기 위한 Annotation이다.

정리를 하자면 json serialize 과정에서 null로 세팅하고자 하면 @JsonIgnore 사용하면 되고, 순환참조에 대한 문제를 해결하고자 한다면 부모 클래스측에 @JsonManagedReference를, 자식측에 @JsonBackReference를 Annotation에 추가해주면 된다.

기본적으로 DTO와 같이 별도의 전달 객체를 활용하여 Mapper를 이용한다면 위와 같은 문제가 없겠지만 경우에 따라 필요한 옵션이 있을 수 있어 찾아보았다.

참조 : binarycube.tistory.com/1

[ERROR] Error running '{ClassName}': Command line is too long. Shorten command line for {ClassName} IntelliJ 실행 에러

코딩하는 너구리 — Sun, 13 Sep 2020 18:33:58 +0900

AWS S3 파일 업로드 작업을 진행하다가 IntelliJ에서 갑자기 오류 발생으로 프로젝트 실행이 되지 않았다.

관련 해결책을 찾다가 xml 수정도 해보았지만 해결되지 않았고, 제대로 된 해결책을 봐서 기록을 남긴다.

우선 에러가 발생하는 이유는

" IntelliJ에서 바로 실행할 때에는 class path를 자동으로 잡게 하는데, 이 때문에 run command가 너무 길어져서 발생하는 문제이다. 정상적으로 실행되는 경우에도 알고 보면 아래처럼 어마 무시하게 run command가 길다."

run command 길이가 OS limit를 넘으면 실행할 수 없게 된다. 이를 해결하기 위해서는 Run/Debug Configuration에서 Shorten command line의 옵션을 수정해야 한다.

4가지 옵션중 하나를 선택할 수 있다.

None: 기본 옵션 값. IDE에서 긴 classpath를 줄여주지 않는다. command line이 OS limit를 초과하는 경우 IDEA는 애플리케이션을 실행할 수 없다. - 에러가 발생했다면 None으로 설정된 상태였을 것이다.
JAR Manifest: IDE는 임시 claspath.jar를 사용해서 긴 classpath 사용을 회피한다. 실제 classpath는 classpath.jar의 MANIFEST.MF 안에 정의되어 있다.
classpath file: text 파일에 긴 classpath를 써둔다.
User-local default: Legacy property이다. IDE는 idea/workspace.xml 파일에서 지정된 옵션 값을 따른다.

쉽게 해결하기 위해서는 Shorten command line 옵션 값을 JAR Manifest로 지정하여 해결하였다.

참고 : deep-dive-dev.tistory.com/45

[ERROR] Can not issue data manipulation statements with executeQuery(). @Modifying 사용하기

코딩하는 너구리 — Tue, 8 Sep 2020 16:03:49 +0900

Can not issue data manipulation statements with executeQuery().

Servlet.service() for servlet [dispatcherServlet] in context with path threw exception [Request processing failed; nested exception is org.springframework.orm.jpa.JpaSystemException: could not extract ResultSet; nested exception is org.hibernate.exception.GenericJDBCException: could not extract ResultSet] with root cause

    @Query(value = "update hashtag set posting_count = posting_count + 1, total_count = total_count + 1 where tag_id = ?1 ", nativeQuery = true)
    void countUp(long userId);

JPA를 이용하여 카운트, 또는 조회수를 카운트하다가 위와 같은 오류가 발생하였다.

이 오류는 UPDATE, INSERT, DELETE문을 사용할 때 executeUpdate()로 전송하지 않았을 경우에 발생한다고 한다.

일반적으로 UPDATE, INSERT, DELETE문이 리턴값을 갖지 않기 때문에 발생하는 에러이다.

그래서 executeUpdate() 메서드의 리턴값은 쿼리를 전송해서 변화한 행의 갯수이다. 글 삭제나 변경같은 일반적인 경우에는 단 하나만 삭제되기 때문에 1이 반환될 것이고, 카테고리를 삭제한다면 가지고 있던 글들이 전부 삭제되어야 하기 때문에 리턴값이 조금 크게 나올 것이며, 의미없는 쿼리를 보낸다면 삭제할 일이 없을 것이기 때문에 0이 리턴될 것이다.

원인을 읽어보면 의외로 해답은 간단하다. executeQuery() 대신 executeUpdate()로 쿼리를 전송하거나, executeUpdate() 대신 executeQuery()로 쿼리를 전송하면 된다.

@Modifying 어노테이션을 붙이지 않으면 결과값 응답을 기대하는 executeQuery() 함수를 사용하게 되는데 delete 쿼리 결과에는 결과값이 없으니 오류가 발생하는 것이다. 따라서 insert, update, delete 쿼리를 실행할 때는 executeUpdate() 함수를 사용하도록 @Modifying 어노테이션을 사용해야 한다.

또한 update 나 delete 쿼리 수행시 @Transactional 어노테이션을 함께 붙여줘야 javax.persistence.TransactionRequiredException 오류를 피할 수 있다.

    @Modifying(clearAutomatically = true)
    @Query(value = "update hashtag set posting_count = posting_count + 1, total_count = total_count + 1 where tag_id = ?1 ", nativeQuery = true)
    void countUp(long userId);

위와 같이 @Modifying 어노테이션을 이용하여 에러를 해결하였다.

추가적으로 clearAutomatically 옵션을 사용하였는데, 아래 설명을 보면 이해에 도움이 될 것 같다.

clearAutomatically

이 Attribute는 @Modifying 이 붙은 해당 쿼리 메서드 실행 직 후, 역속성 컨텍스트를 clear 할 것인지를 지정하는 Attribute 입니다. default 값은 false 입니다. 하지만 default 값인 false를 그대로 사용할 경우, 영속성 컨텍스트의 1차 캐시와 관련한 문제점이 발생할 수 있습니다.

참고:

https://ammff.tistory.com/96

m.blog.naver.com/PostView.nhn?blogId=kgj1&logNo=221115307403&proxyReferer=https:%2F%2Fwww.google.com%2F

devhyogeon.tistory.com/4

[ 프로그래머스 ] 문자열 내 마음대로 정렬하기 JAVA

코딩하는 너구리 — Fri, 28 Aug 2020 23:04:51 +0900

문자열 내 마음대로 정렬하기

문제 설명

문자열로 구성된 리스트 strings와, 정수 n이 주어졌을 때, 각 문자열의 인덱스 n번째 글자를 기준으로 오름차순 정렬하려 합니다. 예를 들어 strings가 [sun, bed, car]이고 n이 1이면 각 단어의 인덱스 1의 문자 u, e, a로 strings를 정렬합니다.

제한 조건

strings는 길이 1 이상, 50이하인 배열입니다.
strings의 원소는 소문자 알파벳으로 이루어져 있습니다.
strings의 원소는 길이 1 이상, 100이하인 문자열입니다.
모든 strings의 원소의 길이는 n보다 큽니다.
인덱스 1의 문자가 같은 문자열이 여럿 일 경우, 사전순으로 앞선 문자열이 앞쪽에 위치합니다.

입출력 예

[sun, bed, car]	1	[car, bed, sun]
[abce, abcd, cdx]	2	[abcd, abce, cdx]

입출력 예 설명

**입출력 예 1** sun, bed, car의 1번째 인덱스 값은 각각 u, e, a 입니다. 이를 기준으로 strings를 정렬하면 [car, bed, sun] 입니다.

**입출력 예 2** abce와 abcd, cdx의 2번째 인덱스 값은 c, c, x입니다. 따라서 정렬 후에는 cdx가 가장 뒤에 위치합니다. abce와 abcd는 사전순으로 정렬하면 abcd가 우선하므로, 답은 [abcd, abce, cdx] 입니다.

import java.util.Arrays;
import java.util.Comparator;
class Solution {
  public String[] solution(String[] strings, int n) {
        Arrays.sort(strings, new Comparator<String>() {
			@Override
			public int compare(String o1, String o2) {
				if(o1.charAt(n) > o2.charAt(n))
					return 1;
				else if(o1.charAt(n) == o2.charAt(n))
					return o1.compareTo(o2);
				else
					return -1;
			}
		});
		return strings;
  }
}

입력으로 주어지는 문자열 strings배열을 바로 정렬하였습니다.

문제 조건에 맞게 정렬하기 위해 Comparator를 사용하였습니다.

charAt() n번째의 문자로 정렬해주었으며,

만약 n번째의 문자가 같을 경우에는 사전순으로 compareTo 함수를 이용하여 정렬해주었습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12915

코딩테스트 연습 - 문자열 내 마음대로 정렬하기

문자열로 구성된 리스트 strings와, 정수 n이 주어졌을 때, 각 문자열의 인덱스 n번째 글자를 기준으로 오름차순 정렬하려 합니다. 예를 들어 strings가 [sun, bed, car]이고 n이 1이면 각 단어의 인덱스 1�

programmers.co.kr

[ 프로그래머스 ] 문자열 내 p와 y의 개수 JAVA

코딩하는 너구리 — Fri, 28 Aug 2020 22:45:23 +0900

문자열 내 p와 y의 개수

문제 설명

대문자와 소문자가 섞여있는 문자열 s가 주어집니다. s에 'p'의 개수와 'y'의 개수를 비교해 같으면 True, 다르면 False를 return 하는 solution를 완성하세요. 'p', 'y' 모두 하나도 없는 경우는 항상 True를 리턴합니다. 단, 개수를 비교할 때 대문자와 소문자는 구별하지 않습니다.

예를 들어 s가 pPoooyY면 true를 return하고 Pyy라면 false를 return합니다.

제한사항

문자열 s의 길이 : 50 이하의 자연수
문자열 s는 알파벳으로만 이루어져 있습니다.

입출력 예

pPoooyY	true
Pyy	false

입출력 예 설명

입출력 예 #1 'p'의 개수 2개, 'y'의 개수 2개로 같으므로 true를 return 합니다.

입출력 예 #2 'p'의 개수 1개, 'y'의 개수 2개로 다르므로 false를 return 합니다.

class Solution {
    boolean solution(String s) {
		boolean answer = true;
		int cnt = 0;
		char ch = ' ';
		
		for (int i = 0; i < s.length(); i++) {
			ch = s.charAt(i);
			if(ch == 'p' || ch== 'P')
				cnt++;
			else if (ch == 'y' || ch == 'Y')
				cnt--;
		}
		if(cnt != 0)
			return false;
		return true;
    }
}

입력으로 주어지는 문자열 s에 대하여

for문을 사용하여 p또는 P라면 cnt++,

y또는 Y라면 cnt--연산을 수행하였습니다.

실행 결과가 0이 아닌 경우에 false를 리턴하고, 0이라면 true를 리턴해주었습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12916

코딩테스트 연습 - 문자열 내 p와 y의 개수

대문자와 소문자가 섞여있는 문자열 s가 주어집니다. s에 'p'의 개수와 'y'의 개수를 비교해 같으면 True, 다르면 False를 return 하는 solution를 완성하세요. 'p', 'y' 모두 하나도 없는 경우는 항상 True를

programmers.co.kr

[ 프로그래머스 ] 문자열 내림차순으로 배치하기 JAVA

코딩하는 너구리 — Thu, 20 Aug 2020 22:38:23 +0900

문자열 내림차순으로 배치하기

문제 설명

문자열 s에 나타나는 문자를 큰것부터 작은 순으로 정렬해 새로운 문자열을 리턴하는 함수, solution을 완성해주세요. s는 영문 대소문자로만 구성되어 있으며, 대문자는 소문자보다 작은 것으로 간주합니다.

제한 사항

str은 길이 1 이상인 문자열입니다.

입출력 예

Zbcdefg

gfedcbZ

import java.util.ArrayList;
import java.util.Collections;

class Solution {
  public String solution(String s) {
		ArrayList<Character> list = new ArrayList<>();
      
		for (int i = 0; i < s.length(); i++) {
			list.add(s.charAt(i));
		}

		Collections.sort(list);
      
		StringBuilder sb = new StringBuilder();
      
		while (list.size() > 0) {
			sb.append(list.remove(list.size() - 1));
		}
      
        return sb.toString();
  }
}

문자를 정렬한 뒤 출력해주는 문제입니다.

먼저, ArrayList를 활용하여 입력으로 주어진 s 문자열을 list에 담아주었습니다.

이후 Collections의 sort 메소드를 사용하여 정렬해주었고

마지막으로 StringBuilder를 사용하여 정렬된 문자열을 출력해주었습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12917

코딩테스트 연습 - 문자열 내림차순으로 배치하기

문자열 s에 나타나는 문자를 큰것부터 작은 순으로 정렬해 새로운 문자열을 리턴하는 함수, solution을 완성해주세요. s는 영문 대소문자로만 구성되어 있으며, 대문자는 소문자보다 작은 것으로 �

programmers.co.kr

[ 프로그래머스 ] 문자열 다루기 기본 JAVA

코딩하는 너구리 — Wed, 12 Aug 2020 12:35:06 +0900

문자열 다루기 기본

문제 설명

문자열 s의 길이가 4 혹은 6이고, 숫자로만 구성돼있는지 확인해주는 함수, solution을 완성하세요. 예를 들어 s가 a234이면 False를 리턴하고 1234라면 True를 리턴하면 됩니다.

제한 사항

`s`는 길이 1 이상, 길이 8 이하인 문자열입니다.

입출력 예

a234	false
1234	true

class Solution {
    public boolean solution(String s) {
        if(s.length() == 4 || s.length() == 6) {
			for (int i = 0; i < s.length(); i++) {
				char ch = s.charAt(i);
				if(ch < '0' || ch > '9')
					return false;
			}
			return true;
		} else
			return false;
    }
}

아주 간단한 문제였습니다.

입력으로 주어지는 문자열 s의 길이를 먼저 확인한 뒤,

주어지는 문자들이 숫자로 구성되어 있는지 확인하였습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12918

코딩테스트 연습 - 문자열 다루기 기본

문자열 s의 길이가 4 혹은 6이고, 숫자로만 구성돼있는지 확인해주는 함수, solution을 완성하세요. 예를 들어 s가 a234이면 False를 리턴하고 1234라면 True를 리턴하면 됩니다. 제한 사항 s는 길이 1 이��

programmers.co.kr

[ 프로그래머스 ] 서울에서 김서방 찾기 JAVA

코딩하는 너구리 — Sat, 8 Aug 2020 21:22:05 +0900

서울에서 김서방 찾기

문제 설명

String형 배열 seoul의 element중 Kim의 위치 x를 찾아, 김서방은 x에 있다는 String을 반환하는 함수, solution을 완성하세요. seoul에 Kim은 오직 한 번만 나타나며 잘못된 값이 입력되는 경우는 없습니다.

제한 사항

seoul은 길이 1 이상, 1000 이하인 배열입니다.
seoul의 원소는 길이 1 이상, 20 이하인 문자열입니다.
Kim은 반드시 seoul 안에 포함되어 있습니다.

입출력 예

[Jane, Kim]

김서방은 1에 있다

class Solution {
  public String solution(String[] seoul) {
      	String tmp = "Kim";
		for (int i = 0; i < seoul.length; i++) {
			if(seoul[i].equals(tmp)) {
				tmp = "김서방은 " + i + "에 있다";
                break;
			}
		}
      return tmp;
  }
}

String temp에 "Kim"을 저장해두고 for문을 이용하여 정답을 찾았습니다.

input으로 주어지는 seoul[i] 번째가 tmp와 같다면,

break한 뒤에 return 해주었습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12919

코딩테스트 연습 - 서울에서 김서방 찾기

String형 배열 seoul의 element중 Kim의 위치 x를 찾아, 김서방은 x에 있다는 String을 반환하는 함수, solution을 완성하세요. seoul에 Kim은 오직 한 번만 나타나며 잘못된 값이 입력되는 경우는 없습니다. 제

programmers.co.kr

[ 프로그래머스 ] 소수 찾기 JAVA

코딩하는 너구리 — Sat, 8 Aug 2020 21:04:41 +0900

소수 찾기

문제 설명

1부터 입력받은 숫자 n 사이에 있는 소수의 개수를 반환하는 함수, solution을 만들어 보세요.

소수는 1과 자기 자신으로만 나누어지는 수를 의미합니다. (1은 소수가 아닙니다.)

제한 조건

n은 2이상 1000000이하의 자연수입니다.

입출력 예

10	4
5	3

입출력 예 설명

입출력 예 #1 1부터 10 사이의 소수는 [2,3,5,7] 4개가 존재하므로 4를 반환

입출력 예 #2 1부터 5 사이의 소수는 [2,3,5] 3개가 존재하므로 3를 반환

class Solution {
  public int solution(int n) {
		int answer = 0;
		boolean[] checked = new boolean[n + 1];

		for (int i = 2; i <= n; i++) {
			if (!checked[i])
				answer++;
			for (int j = i; j <= n; j += i) {
				if (!checked[j])
					checked[j] = true;
			}
		}      
      return answer;
  }
}

이전에 공부했었던 에라토스테네스의 체를 활용하여 풀이하였습니다.

**에라토스테네스의 체에 대해 알고 있다면 풀이에 도움이 될 것 같아 관련 자료를 찾아보았습니다.**

![img](https://blog.kakaocdn.net/dn/LucuQ/btqARxJsGyA/NgJbnKpoDwLeXhNQefa9ZK/img.gif)

**출처 : 위키백과**

https://ko.wikipedia.org/wiki/%EC%97%90%EB%9D%BC%ED%86%A0%EC%8A%A4%ED%85%8C%EB%84%A4%EC%8A%A4%EC%9D%98_%EC%B2%B4

에라토스테네스의 체 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 수학에서 에라토스테네스의 체는 소수(素數, 발음: [소쑤])를 찾는 방법이다. 고대 그리스 수학자 에라토스테네스가 발견하였다. 알고리즘[편집] 2부터 소수를 �

ko.wikipedia.org

**먼저 소수를 찾기 위해 boolean 배열 checked를 만들었습니다.**

**그리고 나서, 2부터 n까지 i의 만큼씩 더해 반복하며 소수에 해당하지 않는 수는**

**checked 배열에 true 처리하여 표시해주었습니다. ( 에라토스테네스의 체와 유사하게 )**

**모두 표시해준 이후 checked 배열이 false인 숫자들만 카운트 해주었습니다.**

출처 : https://programmers.co.kr/learn/courses/30/lessons/12921

코딩테스트 연습 - 소수 찾기

1부터 입력받은 숫자 n 사이에 있는 소수의 개수를 반환하는 함수, solution을 만들어 보세요. 소수는 1과 자기 자신으로만 나누어지는 수를 의미합니다. (1은 소수가 아닙니다.) 제한 조건 n은 2이상

programmers.co.kr

[ 프로그래머스 ] 수박수박수박수박수박수?

코딩하는 너구리 — Wed, 5 Aug 2020 22:06:52 +0900

수박수박수박수박수박수?

문제 설명

길이가 n이고, 수박수박수박수....와 같은 패턴을 유지하는 문자열을 리턴하는 함수, solution을 완성하세요. 예를들어 n이 4이면 수박수박을 리턴하고 3이라면 수박수를 리턴하면 됩니다.

제한 조건

n은 길이 10,000이하인 자연수입니다.

입출력 예

3	수박수
4	수박수박

class Solution {
  public String solution(int n) {
      	int m = n;
		StringBuilder sb = new StringBuilder();
		while (n > 0) {
			if ((m - n) % 2 == 0)
				sb.append("수");
			else
				sb.append("박");
			n--;
		}
		return sb.toString();
  }
}

StringBuilder를 사용하여 풀이하였습니다.

변수 m을 만들어 시작할 때의 n 값을 저장한 뒤

**(m-n) % 2 == 0** 연산으로 n을 1씩 감소하며 문자를 덧붙여주었습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12922

코딩테스트 연습 - 수박수박수박수박수박수?

길이가 n이고, 수박수박수박수....와 같은 패턴을 유지하는 문자열을 리턴하는 함수, solution을 완성하세요. 예를들어 n이 4이면 수박수박을 리턴하고 3이라면 수박수를 리턴하면 됩니다. 제한 조��

programmers.co.kr

[ 프로그래머스 ] 문자열을 정수로 바꾸기 JAVA

코딩하는 너구리 — Wed, 5 Aug 2020 21:54:36 +0900

문자열을 정수로 바꾸기

문제 설명

문자열 s를 숫자로 변환한 결과를 반환하는 함수, solution을 완성하세요.

제한 조건

s의 길이는 1 이상 5이하입니다.
s의 맨앞에는 부호(+, -)가 올 수 있습니다.
s는 부호와 숫자로만 이루어져있습니다.
s는 0으로 시작하지 않습니다.

입출력 예

예를들어 str이 1234이면 1234를 반환하고, -1234이면 -1234를 반환하면 됩니다. str은 부호(+,-)와 숫자로만 구성되어 있고, 잘못된 값이 입력되는 경우는 없습니다.

class Solution {
  public int solution(String s) {
      return Integer.parseInt(s);
  }
}

JAVA 언어를 사용하는 사람들에게는 너무 쉬운 문제입니다.

Integer.parseInt() 함수를 사용하였습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12925

코딩테스트 연습 - 문자열을 정수로 바꾸기

문자열 s를 숫자로 변환한 결과를 반환하는 함수, solution을 완성하세요. 제한 조건 s의 길이는 1 이상 5이하입니다. s의 맨앞에는 부호(+, -)가 올 수 있습니다. s는 부호와 숫자로만 이루어져있습니

programmers.co.kr

[ 프로그래머스 ] 시저암호 JAVA

코딩하는 너구리 — Sat, 1 Aug 2020 11:33:15 +0900

시저암호

문제 설명

어떤 문장의 각 알파벳을 일정한 거리만큼 밀어서 다른 알파벳으로 바꾸는 암호화 방식을 시저 암호라고 합니다. 예를 들어 AB는 1만큼 밀면 BC가 되고, 3만큼 밀면 DE가 됩니다. z는 1만큼 밀면 a가 됩니다. 문자열 s와 거리 n을 입력받아 s를 n만큼 민 암호문을 만드는 함수, solution을 완성해 보세요.

제한 조건

공백은 아무리 밀어도 공백입니다.
s는 알파벳 소문자, 대문자, 공백으로만 이루어져 있습니다.
s의 길이는 8000이하입니다.
n은 1 이상, 25이하인 자연수입니다.

입출력 예

AB	1	BC
z	1	a
a B z	4	e F d

class Solution {
  public String solution(String s, int n) {
      	StringBuilder sb = new StringBuilder();

		for (int i = 0; i < s.length(); i++) {
			char ch = s.charAt(i);

			if (ch >= 'a' && ch <= 'z') {
				ch = (char) (ch + n);
				if (ch > 'z')
					ch -= 26;
			} else if (ch >= 'A' && ch <= 'Z') {
				ch = (char) (ch + n);
				if (ch > 'Z')
					ch -= 26;
			}

			sb.append(ch);
		}

		return sb.toString();
  }
}

StringBuilder와 문자의 덧셈을 이용하여 풀이하였습니다.

먼저 각 문자가 소문자인 경우 if (ch >= 'a' && ch <= 'z') 와

대문자인 경우 else if (ch >= 'A' && ch <= 'Z') 로 나누었습니다.

각각의 경우에 모두 ch에 n을 더해주었고 'z' 혹은 'Z' 보다 커지는 경우에는 -26 연산을 이용하였습니다.

출처 : https://programmers.co.kr/learn/courses/30/lessons/12926

코딩테스트 연습 - 시저 암호

어떤 문장의 각 알파벳을 일정한 거리만큼 밀어서 다른 알파벳으로 바꾸는 암호화 방식을 시저 암호라고 합니다. 예를 들어 AB는 1만큼 밀면 BC가 되고, 3만큼 밀면 DE가 됩니다. z는 1만큼 밀면 a가

programmers.co.kr