제품이 JDK6 그리고 JDK7을 주로 사용하다보니 Calendar와 Date 사용에 익숙했었지만,

요즘 JDK8을 사용하며 다시 Time관련쪽을 살펴볼일이 있었습니다.

(이전에는 JodaTime도 써보고 했지만.. 하위버전에 Date와 Calendar가 익숙하다보니..)

때문에 JDK8에 신규로 등장한 LocalDateTime과 LocalDate, LocalTime에 대해 살펴보고

왜 변경되었는지 살펴볼 예정입니다.

Calendar, Date 문제점 및 불편하던점

1. 불변 객체가 아님

 - 객체를 외부에서 조작해서 문제가 생길수도 있음

 - 외부로 노출될때는 카피를 해서 노출하도록 해야함

2. int 상수 필드 남용

  - Calendar에서 set 하는 경우 Calendar의 상수를 사용하는데, 예를 들면 'Calendar.DAY_OF_MONTH', 상수로는 파악하기 어려움

3. 월 지정

  - 월지정에 1월을 0으로 표현, 1일은 1로 표현, 12를 넣어도(13월이 되는) 에러발생하지 않음

4. 일관성 없는 요일 상수

  - Calendar에서 일요일은 1, Date에서 일요일은 0

5. 불필요한 클래스 분리

  - 기존은 Date만 존재, 국제화 사용, 날짜 단위 계산 등으로 인해 Calendar 추가

  - 최종 결과물이 Date인 경우, Calendar를 통해 Date를 재생성,

  - Calendar의 생성비용은 비싼편

  - 날짜 시간을 모두 저장하는 클래스이름이 Date라는 부분

6. 오류 발생시키지 않는 시간대 지정 

  - TimeZone 지정에 오류가 있더라도 오류를 발생시키지 않는

7. java.util.Date 하위 클래스 문제

  - jdbc 활용시 사용되기도 하는 java.sql.Date는 상위 클래스와 이름이 같다

  - TimeStamp 클래스는 Date에 나노초를 더한 클래스, equals의 대칭성 문제가 발생할 수 있음

참고 및 출처 : https://d2.naver.com/helloworld/645609

8. SimpleDateFormat의 Thread-Safe 하지 않음

  - Date를 포맷팅 하기 위해 주로 사용되는 SimpleDateFormat는 ThreadSafe하지 않아 매번 생성하곤 합니다(혹은 sync를 잡아서..)

  - 신규로 추가된 DateTimeFormatter는 Thread-safe 합니다, 즉 한번 생성하고 재활용해서 여러 스레드에서 쓸수 있습니다.

JDK8 에서 추가된 LocalDateTime, LocalDate, LocalTime

  - LocalDateTime : 시간과 날짜 표현

  - LocalDate : 날짜만 표현

  - LocalTime : 시간만 표현

추가된 Time 클래스 특성

위에 특성들이 개선된 내용들이겠지만 몇가지만 보면

  - 불변클래스로 디자인

    - 생성자가 아닌 static 메소드를 통해 객체를 생성하도록 하며, 다양한 메소드로 다양한 요건들 충족할 수 있도록 지원

    - 3개 클래스 모두 상속을 막은 final class

    - 3개 클래스 모두 Temporal, TemporalAdjuster 인터페이스 구현

      - Temporal(시간) : TemporalAccessor를 상속 받은 인터페이스, plus 및 minus 메소드 지원

        - TemporalAccessor : get 및 query , getLong

      - TemporalAdjuster(시간조정자) : adjusInto 메소드 지원, DateTime에 adjusInto(LocalDate)를 하면 Time은 그대로 Date만 변경

Date & Calendar 사용법과 많이 달라 메소드를 다양하게 사용해봐야 할것

자바에.. SortedQueue가 있는줄 알았는데...

없다..?;;;

"왜 있는줄 알았지?" 하고 찾아보니 SortedQueue는 없지만 SortedSet이 있었다..

역시 툴 자동완성을 자주 쓰다보니..

헤깔렸다보다..(뭐.. 그냥 인터페이지 차이 뿐이니..)

다만 한가지 더는 TreeSet은 Queue쪽 인터페이스는 안되고

(하긴 지금 생각해보니 당연한건가.. set이랑 queue랑 조금 의미가 안맞긴하겠다.. 그냥 쌓이는 queue랑 중복 제거하는 set이랑..)

의도대로 하려면 Queue queue = new PriorityQueue<>(Comparator)...

Queue queue = new PriorityQueue<>((o1,o2)->o2.cnt-o1.cnt)...

그리고 하나더

TreeSet은 add한 후 add한 객체를 변경하면 순서가 변경되지 않는다.

PriorityQueue도 그런가? 했는데 테스트 해보니 마찬가지로 동작한다(add할때 순서가 정해지는 가보다..).

마지막으로

TreeSet에 add한 객체를 수정해도 순서가 안바뀌긴 하는데

remove를 하고 add하면 당연히 바뀌겠지만..

remove 안하고 add하면 어떻게 될까..?

테스트 해보니 결과는 "순서가 바뀌지 않았다"

필요한대로 동작하는지

항상 조금씩 유닛테스트를 돌리면서 진행하다보니..

이런 폐해가...

이런 실수도 실력이니..

다시 실수 안하기 위해 까먹지 않기위해 끄적끄적..

카프카는 파티션 갯수를 늘리고 다시 줄일수 없다고 해서

토픽을 삭제 후 다시 생성하기 위해

kafka-topics.sh 를 통해(window에서 테스트를 해서 실제로는 .bat)

topic을 삭제 했습니다.

그런데. . kafka 브로커가 다운되더니.. 부팅되지 않는 문제가 발생하기 시작했습니다.

(부팅시 에러는 삭제한 토픽 파일을 읽는데 파일 권한에러..인데.. 전혀 접근 권한 문제 일으킬만한건 없습니다)

그래서 이런저런 글들을 살펴보며 겪은 부분들을 남깁니다...

먼저 delete.topic.enable=true

를 설정 하지 않아서 kafka-topics로 삭제했을때 마크만 된 상태였습니다.

그래서 위 설정을 해줬지만 마찬가지로 정상 부팅은 되지 않았습니다

(지금 생각해보니 설정을 하고 kafka-topics로 다시 삭제를 해볼껄 그랬나봅니다..)

(그런데.. 생각해보니 kafka-topics로 삭제할때 IP:PORT는 zookeeper쪽을 입력해줬는데.. 의미가 있나.. 싶네요)

두번째로 시도한건 recovery-point-offset-checkpoint, replication-offset-checkpoint 수정 입니다.

글을 보니 다른 브로커로 파티션 옮길때 수정하는 것으로 보이던데

이 방법을 시도해본 이유는 

"나는 토픽을 삭제했는데 왜 해당 토픽 관련 에러가 나는것인가?, 해당 토픽 내용들을 다 삭제해야 겠다"

였습니다.

파일 구조는 recovery~~~나 replication~~ 이나 거의 유사 했고

0
59
__consumer_offsets 22 0
__consumer_offsets 30 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 4 0
__consumer_offsets 27 0
__consumer_offsets 7 0
__consumer_offsets 9 0
__consumer_offsets 46 0
topic3 0 0
__consumer_offsets 25 0
__consumer_offsets 35 0
__consumer_offsets 41 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 49 0
topic2 0 0
__consumer_offsets 47 0
__consumer_offsets 16 0
__consumer_offsets 28 0
__consumer_offsets 31 0
__consumer_offsets 36 0
__consumer_offsets 42 28
__consumer_offsets 3 0
__consumer_offsets 18 0
__consumer_offsets 37 0
bars 0 0
__consumer_offsets 15 0

이런식이였습니다, 자세한 정보를 추가로 찾아봐야겠지만

두번째 줄에 59는

두줄을 빼고 데이터부가 59라인이 있다는것을 말합니다.

(결국 마지막 데이터 줄은 61라인)

그래서 삭제할 토픽의 데이터의 offsets 디렉토리 정보와 토픽 정보를 라인을 삭제하고 두번째 라인에서 값을 빼줬습니다.

그후, 부팅해보니 수정했던 replication-offset-checkpoint 가 다시 삭제했던 내용들을 복원해놓고 있었습니다

(대체 토픽정보를 어디서 복원을 하는거지.. 레플리카 구성한것도 아니고..)

마지막 세번째, 파일들은 대략 다 열어 봤고 마지막 의심가는건 zookeeper밖에 없었습니다

zookeeper 데이터를 찾아보니 /brokers/topics 에 삭제했던 topic 정보가 남아있었습니다

rmr /brokers/topics/대상토픽

으로 삭제하고 

replication-offset-checkpoint를 수정 후

broker를 띄우니 잘 뜨는것을 확인했습니다.

지금은 토픽을 그냥 삭제하는데 발생한 이슈였지만.. 운영중에 갑작이 이렇게 부팅이 안되는 문제가 발생하면.....;;;;

kafka를 사용하는 방법도 더 해봐야겠지만

내부 파일 구조 체계들을 알아둬야 이런 난감한 상황에 잘 대처 할 수 있을것 같습니다

kafkaMessageListener를 살펴보다가 

SmartLifecycle을 통해 org.springframework.kafka.listener.ConcurrentMessageListenerContainer 를 start 시키는것을 보고

SmartLifecycle과 LifeCycle에 대해 조금 살펴보았습니다.

추후 이와같이 서버 기동시에 세팅하고 종료 시키는 Bean이 필요하면 써먹으면 어떨까 합니다.

기존에는 초기화 Bean 을 만들고 @PostConstruct를 달아 초기화 로직을 돌리고 종료는 알아서 하곤 했습니다.

org.springframework.context.SmartLifeCycle은 Lifecycle, Phased 인터페이스를 구현한 인터페이스 입니다.

SmarLifeCycle을 살펴보기 이전에 LifeCycle을 살펴보고 SmarLifeCycle 을 살펴보겠습니다.

LifeCycle

LifeCycle은 라이프 사이클을 컨트롤 하기위해 start(), stop(), isRunning() 메소드로 구성되어 있으며

주석을 살펴보니 LifeCycle 인터페이스는 자동실행은 담당하지 않고 자동실행을 하고 싶으면"SmartLifecycle"을 활용하라고 되어있습니다.

Bean이 LifeCycle 인터페이스를 구현한다면 ApplicationContext에서 Start와 Stop 시그널을 준다고 되어있고

JMX를 통해서도 제어 가능하다고 되어있습니다

그리고 주요한 부분중 하나는 Scope가 "싱글톤" 일때만 동작한다는 것 입니다.

(테스트 해보니 "프로토타입"의 경우 동작하지 않는것을 확인 했습니다.)

(서버 다운시 ShutDown Hook에서 동작하다 보니 프로토타입은 적합하지 않나봅니다)

(동작하려면 서버 종료때까지 Bean이 살아있어야 한다는 말이기 때문에..)

SmarLifeCycle

SmarLifeCycle은 위에 적은대로 Lifecycle, Phased 를 구현한 인터페이스이지만 LifeCycle과 동작이 조금 다릅니다.

종료시점에 isRunning을 체크하여 stop을 호출해준다는 부분은 같지만

앞에 설명대로 SmartLifeCycle은 자동 실행으로 기동시점에 start() 메소드를 호출해줍니다.

DefaultLifecycleProcessor:140에 startBeans를 보면, 두 가지 Bean 모두 lifecycleBean 맵에 존재 하지만 체크로직으로 SmarLifecycle Bean만 phases에 들어가는 것을 볼수 있고 하단에 start()를 호출해주는 부분을 볼수 있습니다.

그리고 종료(stop)하는 부분도 LifeCycle살짝 다르긴한데

DefaultLifecycleProcessor:221에 doStop을 보면, SmarLifecycle은 Callback을 넘겨받는 stop이 불리며

Lifecycle은 단순 stop만 호출하고 끝나는 것을 볼수 있습니다.

서버 다운시 돌고있는것을 정리만 해주기 원한다면 Lifecycle을 

서버 부팅시 start, 종료시 stop 모두 서버와 Lifecycle을 함께 간다면 SmartLifecycle Bean을 고려해보는것도 좋을것 같습니다.