스프링부트 with JPA 프로젝트 작업중 신기한게 로컬환경에서는 에러가 안났는데 alpha, real환경에만 배포하면 위와 같은 에러 메세지가 나왔다....
Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Either use @Param on all parameters except Pageable and Sort typed once, or none at all!
문제의 원인이 무었이었는고 하니...
JPA 에서 매개변수 2개를 받는 메서드에 한 변수에만 @Param을 지정해서 사용하여서 발생하였다...
jobId 매개변수에도 @Param을 명시적으로 주니 정상적으로 해결 되었다.
void upsertAnalysisData(@Param("jobId") int jobId, @Param("audience") AudienceAnalysis audienceAnalysis);
혹시나 비슷한 에러가 발생한다면 JPA Repository부분에 특정 매개변수에만 @Param을 주어서 사용하진 않았는지 확인해보자!
보통 impala(임팔라)에서 임시 테이블을 생성 후 해당 테이블의 데이터를 기존 Imala의 데이터와 Join(조인)해서 사용해야 할 경우 다음과 같이 테이블을 생성 후 해당 경로에 데이터를 밀어넣어 준다.
create table DBNAME.TABLENAME (uid STRING) row format delimited fields terminated by ' ' LOCATION "hdfs:///user/hive/warehouse/특정원하는디렉토리명칭/“;
문제는 해당 명령어로 TABLE을 만들고 Imapa shell상에서 drop table [테이블명] 을 하였을 때 LOCATION으로 지정된 HDFS 파일은 남아 있게 되고 hadoop 명령어로 따로 지우려고 하면 보통 Hadoop 명령어 실행 권한과 해당 경로에 파일을 쓴 권한 [Impala] 가 달라서 Permission denied되며 삭제 되지 않는다.
따라서 해당 테이블을 Impala 테이블에서 Drop시키면서 연결괸 HDFS File도 함께 삭제 하고 싶다면 'PURGE' 옵션을 함께 주자.
위와 같이 request의 scheme이 'http'가 아닌 경우 'https'로 리다이렉트 하도록 되어져 있다.
따라서 http로 요청을 하였을 때는 당연히 acces_log를 안찍을 거라고 생각을 했는데....아니였다.....
nginx는 기본적으로 요청이 들어왔을 때 현재의 스코프내에서 정의되어져 있는 access_log가 있다면 해당 경로에 access log를 남기고 그렇지 않다면 그 상위 스코프에 있는 access_log에 접근해 access log를 남긴다는 것이다. 자바스크립트의 hoisting(호이스팅)과 비슷한 느낌이다.
따라서 'http'요청일 경우 access log를 남기고 싶지 않다면 if 블럭에 'access_log off'를 주어 access log를 남기지 않도록 한다.
Similar to the error_log directive, the access_log directive defined on a particular configuration level overrides the settings from the previous levels. When processing of a request is completed, the message is written to the log that is configured on the current level, or inherited from the previous levels. If one level defines multiple access logs, the message is written to all of them.
jar로 작업된 스파크 프로젝트를 spark-submit 실행시 아래와 같은 에러가 발생했다.
RejectedExecutionException은 첨 겪어봐서 당황했지만....문제의 원인은 단순했다.
java.util.concurrent.RejectedExecutionException: Task org.apache.spark.scheduler.TaskResultGetter$$anon$2@ab4016a rejected from java.util.concurrent.ThreadPoolExecutor@9c5a328[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 603] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
프로젝트 빌드시 spark driver셋팅을 잘못해준것...
trait InitSpark {
// for local
// val sparkConf = new SparkConf().setAppName("Spark-1.6.x-sample").setMaster("local[*]").set("spark.driver.host", "localhost");
// for build
val sparkConf = new SparkConf().setAppName("Spark-1.6.x-sample")
val sc = new SparkContext(sparkConf)
val sqlContext = new HiveContext(sc)
}
로컬모드 (setMaster("local[*]").set("spark.driver.host", "localhost") 로 빌드하고 돌려서 문제가 되었다...
보통은 작업한 스파크 버전과 spark-submit을 실행하는 환경의 스파크 버전이 달라도 발생하는 에러메세지라고 한다.
2020년이 시작하고 1월 토이프로젝트에 설까지 너무 빨리지나가버렸다. 그렇게 1월 포스팅 하나 하지 못한 채 2월을 맞이하게 되었다. 너무빨리지나가는 시간이 무섭기도 하고 1월 한달간 포스팅하나 제대로 못한 것이 맘에 꽤나 걸렸다.
그 순간 문득 2월은 한 달간 1일 1포스팅을 해보면 어떨까? 하는 생각이 들었다. 생각이 한 번들자 실제로 실천했을 때 1월과 방문자수는 얼마나 차이가 날지도 궁금했고 2월은 짧으니까! 할 수 있겠다라는 자신감이 들었다. 그런데 4년에 한 번 돌아오는 윤달인지는 알지 못했고...2월 29일인 지금 이렇게 마지막 포스팅을 남기고 있다^^
처음 호기롭게 시작하고 약 10일 간은 굉장히 수월했던 것 같다. 기존에 생각만하고 포스팅하지 못했던 주제들에 하나 두개씩 글을 써나가기 시작했고 전에 소재들에 대해 생각해논 덕분에 10일까지는 별어려움없이 진행되었다. 문제는 그 이후 부터였다. 보통 개발을 하다가 특정 문제에 부딪혔을 때 그 문제들을 해결해나가며 몰랐던 부분에 대해 포스팅하거나 경험해보지 못했던 이슈트래킹을 한 경우에 대해서 포스팅을 했었는데 이제 나도 어연 개발자로 일한지 6년차로 접어들었고 왠만한 문제는 한 번씩은 겪어보았던 탓에 주기가 그렇게 짧지가 않았다. 그렇기에 연달아 10일을 포스팅하고 나니 소재가 다 떨어져 내가 이 도전과제를 잘 끝까지 마무리할 수 있을까하는 생각이 들었다.
그렇게 10일 이후 소재가떨어지기 시작하며 기존에 사놓았지만 보진 못했던 책들을 하나 둘 펼치게 된다. 모르는 내용이나 쉽게 지나쳤던 내용들 중 알아두면 좋을 만한 내용들을 찾기 시작했다. 물론 포스팅을 위해서였다. 이러다보니 뭔가 주객전도가 된듯한 느낌을 받았다. 그래도 어떻게 좋은 내용들을 발췌해 포스팅을 해나가며 시간은 어느덧 20일을 향해 나아가고 있었고 이제 얼마안남았다는 생각이 들었다.
15일 정도 꾸준히 포스팅을 하다보니 반 이상왔다는 생각에 더더욱 꼭 한 달간 1일 1포스팅 도전을 성공적으로 마무리짓고 싶었다. 그래서 약속이 있는 날이나 바쁠 것 같은 날에는 그 전날 미리 포스팅을 하여 예약을 걸어놓기도 하였다. 그렇게 성공적으로 1일 1포스팅 목적을 달성을 코앞에 두고 있고 마지막 포스팅을 작성해 나가고 있다.
2월 한 달간 1일 1포스팅을 하며 느낀점은 다음과 같다. 생각보다 나는 생각만하고 행동으로 빠릿빠릿하게 하는 타입은 아니였다는걸 깨달았다. 포스팅해야지 하고 항상 소재만 생각해놓고 미뤄놓았던 이전의 내 모습들을 보며 느꼈고 항상 하루의 막바지즈음에나 급하게 포스팅을 하는 나의 모습을 보면서도 느꼈다. 요즘드는 생각이지만 시간을 좀 더 효율적으로 보내는 노력을 더 해야 할 것 같다. 그리고 1일 1포스팅의 취지는 좋았지만 내게는 맞지 않는 방식이라는 생각이 들었다. 물론 포스팅을 하는 과정에서 조금이라도 더 전공책을 보려하고 전공지식의 포스팅들을 보며 공부하는 시간은 늘었지만 심리적인 압밥감과 스트레스로 다른 내가 하고 있는 것들에 대해 어느정도 영향이 미쳤던 것 같다. 하지만 꼭 한 번은 해보고 싶은 도전이였고 이렇게 성공적으로 마칠 수 있어 너무 행복하다. 이제 2020년 남은 날들은 좀 더 심도있는 글들을 남겨나가고 싶다. 너무 목표 성취만을 위해 성의 없는 포스팅을 하기도 했었다. 그 당시 나에게는 그 하루로 인해 1달 목표를 망치기 보다 일단 포스팅을 함으로써 내 도전과제를 이어나가고 싶은 욕심이 더 컸었기 때문이다. 하루는 3분 남기고 포스팅을 완료짓기도 했다ㅎㅎ
그럼 한 달 동안 1일 1포스팅을 하며 방문자수는 얼마나 차이가 났을까?
전 달(1월)과 비교했을 때는 4천 이상 방문수가 차이가 났고 2019년과 2018년에 비해서는 1만 이상의 차이를 보였다ㅎㅎ이렇게 보니 성장해나가고 있다는 생각에 기분이 좋다. 글을 쓰는 만큼 조금씩 방문해주는 사람도 늘어나고 있고 그걸 수치가 증명해주고 있어 잘해나가고 있다는 생각이 든다.
항상 생각한다. 나는 머리가 똑똑하지도 않고 게으름도 많은 편이지만 항상 내가 생각하고 계획했던 것들을 꾸준히 해나가는 성실함이 큰 무기인 것 같다. 앞으로도 이 성실한 모습을 바탕으로 다양한 것들에 많이 도전해보고 실천해 나가고 싶다. 조금더 부지런해질 필요가 있고 주어진 시간에 대해 좀 더 효율적으로 쓸 수 있도록 노력하자!!!!
2월 한달 간 읽었던 포스팅 중 유익했던 블로그 글들에 대해 정리해보려 한다. 총 3개의 글로 현재 개발 6년차인 나에게 부족했던 부분에 대한 지식을 완고히 해주었거나 너무 익숙해서 그냥 지나쳤던 것들에 대해 다시 한 번 생각해 보게 하는 글들이였다.
1. Java, max user processes, open files (관련한 발생가능한 문제와 해결에 관한 글)_
실제 서비스를 운영하다 보면 리눅스의 커널 설정을 변경해주어야 하는 경우가 종종 발생한다. 예를 들어 request가 유실된다던지 open files의 설정과 max user processes의 설정이 낮게 잡혀있어 요청처리율이 낮은 경우입니다. 이외에도 tcp timeout과 같은 네트워크 적인 설정 부분도 있지만 해당 포스팅에서는 주로 접할 수 있는 open files로 인한 문제와 그로 인한 테스트 해결책들을 상세하게 설명하여 기존에 대략적으로 알고 있던 부분에 대한 내용에 대해 다시 한 번 리마인드할 수 있었습니다.
애플리케이션이 시작될 대 어떤 클래스가 최초 한 번만 메모리에 할당되고 그 메모리에 인스턴스를 한 번 만들어놓고 지속적으로 가져다 사용하는 디자인 패턴인데요. 아마 스프링을 쓰시는 분들은 @Bean이라는 어노테이션을 통해 많이들 사용하고 계시리라 생각됩니다. 하지만 싱글톤 패턴의 장점은 잘알고 있지만 단점에 대해서 잘 모르고 저 또한 사용하고 있었고 해당 포스팅에서는 @Bean 어노테이션을 사용하지 않고 싱글톤 패턴을 구현하는 방법들에 대해 설명해 주고 있으며 일반적으로 알고 있는 잘못된 방법에 대해서도 설명해 줍니다. 실제 멀티쓰레드 환경에서 자바 모듈을 구현해야하는 분들이시라면 읽어보면 많은 도움이 되실 것 같습니다.
이전에 적어놓았던 독서노트 문구중 공유할만한 문구 몇 가지를 소개해볼까 한다. 어떤 책인지는 적어놓지 않아 모르겠다ㅠㅠ
개발자로 일을 하고 있지만 나 또한 처음 개발자로 취업한 것이 결코 코딩을 하는 것이 즐겁거나 재미있어서가 아니였다. 하지만 지금은 하루 하루 코딩하며 개발자로서의 삶을 살아 갈 수 있다는 것이 큰 기쁨이다. 어떻게 이렇게 된걸까?라고 생각을 해보면 분명 힘든 시절이 있었다. 남들과의 비교로 내 실력이 형편없어 보일 때 오는 좌절감과 특정 기능 구현에서 막혔을 때의 막막함이 있었지만 그런 고통 속에서 나는 하루 하루 성장해 나갔던 것 같다. 그렇게 다양한 문제들에 직면하고 해결하는 과정, 비교로부터오는 좌절감을 극복하기 위한 공부는 내 개발실력을 조금씩 향상시켜주었다. 사람은 이기적인 동물이라 내가 잘하는 것은 재밌다고 느낄 확률이 크고 잘 하지 못하는 것에 대해서는 하기 싫은 법이다. 적성에 맞는지 안맞는지는 내가 그 일을 '잘한다'라는 생각이 들 위치까지 올랐을 때 잘함에도 불구하고 흥미를 느끼지 못하거나 더이상 하고 싶지 않을 때 생각해봐도 충분하다고 생각한다. 일단 지금의 일을 잘하기 위해 노력부터 해보자.
아래의 문구들은 나의 위의 생각들을 뒷받침해주는 내용이기에 공감이 가서 노트에 적어 놓았던 것 같다.
인생을 행복하게 보내려면 자신이 좋아하는 일을 해야 한다고 말하는 사람이 많다. 자신이 좋아하는 일을 해야 능률이 오르고 집중할 수 있다고 말이다. 그러나 처음부터 자신이 좋아하는 분야를 선택해 평생 자신의 직업으로 삼는 사람이 얼마나 될까? 애석하게도 그런 사람은 1,000명 중 한 명이 될까 말까다. 더구나 자신이 좋아하는 회사에 들어갔더라도 본인이 희망하는 부서에 배치되고, 자신이 원하는 일을 하는 사람은 1만 명 중 한 명도 되지 않는다. 그렇다면 1,000명 중 999명 1만 명 중 9,999 명은 불행하고 좋아하지도 않는 일을 억지로 해야 하기 때문에 능률이 떨어진다고 봐야 할까? 그렇지 않다. 오히려 자신이 좋아하지 않는 분야에서 출발했지만 그 분야에서 두각을 나타내는 사람이 크게 성공할 수 있다.
자신에게 주어진 일이 천직이라는 마음으로 즐겁게 일하는 것이 중요하다. 주어진 일이라서 어쩔 수 없이 한다는 생각을 버리지 않으면 절대로 일하는 고통에서 벗어날 수 없다.
자기가 좋아하는 일을 추구하는 것은 유토피아를 찾는 것과 같다. 유토피아는 화려하지만, 현실에서는 절대 이루어질 수 없다. 유토피아는 유토피아일 뿐이다. 그래도 유토피아를 현실에서 이루고 싶다면, 지금 자신 앞에 놓인 일을 먼저 사랑하라.
할 수 없다고 생각하면 아무것도 할 수 없지만, 할 수 있다고 믿으면 아무리 캄캄한 어둠 속에서도 반드시 길어 보이는 법이다.
