Minato's Life

jad -o -r -sjava -8 -dtest target/**/*.class

-o : 덮어쓰기

-r : 해당 패키지 형태로 디렉토리 구조를 만듬(restore package directory structure)
-s java : 디컴파일된 파일의 확장자를 java로 생성

-8 : 유니코드 스트링을 ANSI 스트링으로 변환, (주로 유니코드 -> 한글)

-d : 디컴파일될 디렉토리(-d <dir> - directory for output files)

마지막은 디컴파일 해야할 타겟 지정 (target/**/*.class -> target 폴더 하위에 존재하는 class파일을 대상으로)

안그래도 DB에 관련된 지식이 완전 바닥인데 거기다 이런일까지 겪게되어 DB가 더 무서워졌다..

"ora-1000" ?.. 누구냐 넌.....

테스트 서버에선 아무 이상 없었는데 운영 서버에서는 대략 5~8시간만에 ora-1000을 내뿜으며 DB가 멘붕이 된다..

검색을 해보니 오픈커서라는게 기본으로 설정된 수치를 초과해서 글탄다. 기본 설정 수치는 300...

또.. connection, preparedStatement,, 등등 열고 닫고를 제대로 못해줘서 그런거라던데...

혹은 loop내에서 대량으로 인서트 혹은 셀렉트 할때라던가...

사실 요즘은 DB도 프레임웍을 쓰기때문에 conn이나 prestatement 이런걸 직접적으로 열고 닫는일은 없다..

직접 열고닫고 한다해도 열고닫는일을 소스상에 도배하는 일은 없을테지 -_-

사실 검색해서 나온 내용들은 너무 오래된 옛날 얘기들이라 현재로써는 문제점으로 삼을수가 없었다.

그리고 난 근본적인 원인을 찾지 못했다. 단지 방어적인 설정으로 일단 인공호흡만 죽어라 하는..;

가장 이해가 안됬던건 무언가 액션이 일어날때 반응하는 오픈커서 갯수는 테스트 서버에서는 20에서 많게는 50~60개? 정도가 쌓이는데 운영서버에서는 최소 80개 정도를 시작으로 300개까지 도달하는 시간이 5~8시간 정도 되는것 같더라..

테스트 서버에서는 300를 채울래야 채울수가 없었고 수치를 50으로 설정해서 테스트를 해서 ora-1000을 재현했다..

여기서 해볼수 있는건 오픈커서를 강제적으로 없애버리는거...

--설정된 커서 갯수 확인

show parameter open_cursors;

--50으로 설정

ALTER SYSTEM SET open_cursors=50;

-- 사용중인 해당 계정에 sid별 오픈커서 확인

select

o.sid, osuser, machine, count(*) num_curs

from

v$open_cursor o, v$session s

where

user_name = 'scott' and o.sid=s.sid

group by o.sid, osuser, machine

order by num_curs desc;

페이지를 이동할때마다 위 쿼리를 실행해보면 커서가 쌓이는걸 볼수 있다..

근데 저런게 한번 열리면 시간이 지나면 알아서 닫혀야 하는거 아닌가? 처음엔 닫히질 않더라.. 줄어들지 않으니 계속 쌓이다 보면 뻗어버리나보지.

할튼 닫아주는게 목적이였으니..

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

<property name="driverClassName" value="${database.main.driverClassName}" />

<property name="url" value="${database.main.url}" />

<property name="username" value="${database.main.username}" />

<property name="password" value="${database.main.password}" />

<!-- 수정 전 

<property name="defaultAutoCommit" value="true" />

<property name="poolPreparedStatements" value="true" /> 아마도 이것때문에 닫히질 않았을꺼라 생각됨. * 참고

<property name="maxActive" value="30" />

<property name="maxIdle" value="10" />

<property name="minIdle" value="3" />

<property name="initialSize" value="3" />

<property name="maxWait" value="10000" />

-->

<!-- 수정 후 --> 

<property name="maxActive" value="100" />

<property name="maxIdle" value="10" />

<property name="minIdle" value="3" />

<property name="initialSize" value="10" />

<property name="maxWait" value="10000" />

<property name="testOnBorrow" value="true" />

<property name="testOnReturn" value="true" />

<property name="validationQuery" value="select 1 from dual" />

<property name="testWhileIdle" value="true" />

<property name="timeBetweenEvictionRunsMillis" value="130000" /> 정해진

<property name="minEvictableIdleTimeMillis" value="120000" /> 시간에 따라

<property name="numTestsPerEvictionRun" value="100" /> 100개씩검사

<property name="removeAbandonedTimeout" value="30" /> 30초 동안 사용하지 않았을때

<property name="removeAbandoned" value="true" /> 삭제

<property name="logAbandoned" value="false" />

</bean>

이 방법이 맞는지도 모르겠고 저렇게 짧은 시간에 커넥션을 확인해서 강제적으로 삭제해주는게 서버에 어떠한 영향을 미칠지.. 그것 조차도 모른다.

아직은 4~5일 정도 문제없이 버텨주고 있고 오픈커서 역시 40~50개 정도가 유지되고 있다는 얘기만 들었다.

이런 문제에 대해 도움을 받고싶어도.. 어디다 물어봐야 하는지도 모르겄다 -_-

이럴수가.. 스프링이 엄청난 발전을 한것 같다.

사실 스프링으로 뭔가를 시작하려면 많은 설정들이 귀찮고 짜증났었는데..

이 아래 설정만으로 스프링을 쉽게 사용할 수 있다...

pom.xml

@SpringBootApplication 이 어노테이션이 설정되면 해당 패키지 밑으로 component-scan을 한다.

https://github.com/muheun/spring-boot

어딘가 블로그를 보면서 테스트겸 하나 만들어봤는데 재미가 솔솔하다..

application.properties에서 contextPath와 port 설정을 해주면 되고..

(물론 그 프로퍼티 파일엔 수많은 설정키를 사용할수 있다. * 참고)

그 외엔 예전에 일할때부터 생각했던거지만 쿼리문 짜는건 쓸대없는 시간낭비라 생각했었다. -_- 물론 지금도 마찬가지...

해서 JPA를 이용해서 ORM기법(?)을 사용해봤고 DB역시 가진게 없기에 H2를 사용해서 그냥 간단한 crud 테스트 해봤다.

또.... 그냥 jsp는 식상한거 같아서 thymeleaf로...

lombok이란것도..

jquery같은것도 maven에서.. 암튼 테스트겸 이것 저것 적용해서 해봤는데 진짜 빠르고 쉽게 공부할수 있었다..

3년만에 다시 공부란걸 해볼라니.. 막막하긴한데 그래도 역시 재밌다! ^^

급 작성인것을 감안해주길..- -;

maven을 사용하여 프로젝트 생성. 프로젝트 구성은 src, test, resources, 정도. jdk7 사용.

Server.java 를 실행하면 대략..

AppConfiguration -> JettyConfiguration -> WebInitializer -> MvcConfiguration 순으로 구동..

기존 방식대로 web.xml, app-context.xml, servlet-context.xml에 설정하고 Server에서 jetty를 구동해도 무관.

최소 목표는 java -jar __myjetty.jar를 실행해서 서버를 띄우는 것.

pom.xml

classpath, main-class, web.xml 경로설정해주고 mvn install 하면 jar 파일 생성.

이런식으로 서버 실행.

* jdk6 버전으로 하는 방법 ( https://github.com/steveliles/jetty-embedded-spring-mvc )

이름 목록에서 "hero"를 삭제하려고 하면 ConcurrentModificationException이 발생한다.

리스트를 순회하는 동안 요소를 추가, 삭제, 수정하면 안되기 때문이다.

그래서 Iterator를 사용한다.

그럼 정상적으로 해당 요소는 삭제된다. 이건 싱글 스레드에선 문제가 없어보인다.

근데 Iterator로 순회하는 도중에 다른 스레드에서 List에 접근하여 조작하려 한다면 어떻게 될까..

iterator는 HashTable이건 List건 부모의 내용이 바뀌지 않는 것을 전제로 사용된다 하기 때문에 분명 똑같은 예외가 발생할 것 같다.

방법은 원본 List는 순회하지 않으면 된다.

clone을 사용하여 복제된 List를 순회시키고 해당 조건문에서는 원본 List의 요소를 삭제하면 아무런 문제가 없어보인다.

물론, 더 좋은 방법이 있을지도 모르겠지만! 나중에 한번 더 고민해보지 뭐.. ;p

구글링 하다가 본 내용인데.. 죄다 영어라 이해하기 힘들다.. 아무튼 CopyOnWriteArrayList를 사용하면 위 문제는 해결된다.

하지만 애초에 우린 CopyOnWriteArrayList 보단 ArrayList를 많이 사용하기 때문에 특별한 경우가 아닌 이상에야 un-safe한 리스트를 사용할 이유가 없다고 생각한다.

암튼, 영어가 익숙해지면 한번 쭉- 읽어봅시다.. ( http://www.javacodegeeks.com/2011/05/avoid-concurrentmodificationexception.html )

CopyOnWriteArrayList 클래스는 동기화된 List 클래스보다 병렬성을 훨씬 높이고자 만들어졌다. 병렬성이 향상됐고, 특히 List에 들어있는 값을 Iterator로 불러다 사용하려 할 때 List 전체에 락을 걸거나 List를 복제할 필요가 없다.

( CopyOnWriteArrayList 와 비슷하게 Set인터페이스를 구현하는 CopyOnWriteArraySet 도 있다. )

'변경할 때마다 복사'하는 컬렉션 클래스는 불변 객체를 외부에 공개하면 여러 스레드가 동시에 사용하려는 환경에서도 별다른 동기화 작업이 필요 없다는 개념을 바탕으로 스레드 안전성을 확보하고 있다. 하지만 컬렉션이라면 항상 내용이 바뀌어야 하기 때문에, 컬렉션의 내용이 변경될 때마다 복사본을 새로 만들어 내는 전략을 취한다. 만약 CopyOnWriteArrayList에서 Iterator를 뽑아내 사용한다면 Iterator를 뽑아내는 시점의 컬렉션 데이터를 기준으로 반복하며, 반복하는 동안 컬렉션에 추가되거나 삭제되는 내용은 반복문과 상관 없는 복사본을 대상으로 반영하기 때문에 동시 사용성에 문제가 없다.

반복문에서 락을 걸어야 할 필요가 있기는 하지만, 반복할 대상 전체를 한번에 거는 대신 개별 항목마다 가시성을 확보하려는 목적으로 잠깐씩 락을 거는 정도면 충분하다.

변경할 때마다 복사하는 컬렉션에서 뽑아낸 Iterator를 사용할 때는 ConcurrentModificationException이 발생하지 않으며, 컬렉션에 어떤 변경 작업을 가한다 해도 Iterator를 뽑아내던 그 시점에 컬렉션에 들어 있던 데이터를 정확하게 활용할 수 있다.

물론 컬렉션의 데이터가 변경될 때마다 복사본을 만들어내기 때문에 성능의 측면에서 손해를 볼 수 있고, 특히나 컬렉션에 많은 양의 자료가 들어 있다면 손실이 클 수 있다. 따라서 변경할 때마다 복사하는 컬렉션은 변경 작업보다 반복문으로 읽어내는 일이 훨씬 빈번한 경우에 효과적이다.

Junit.. 단위 테스트.. 처음 접하게 된건 비X교육센터를 다니면서 어설프게 사용을 해봤고,

첫 직장에서는 그 어설픔으로 java, 클래스 파일만 쓸데없이 늘려나갔고 -_-

현, 두번째 직장에서는 나름 단위 테스트 답게 사용하고 있다. 물론 100% 활용이라고 까진 못말하지만 말이다...T^T

지금 직장에서 배우면서 가장 많이 들었던 말은.. 남들이 내 코드를 읽어내려갈때 쉽게 읽힐수 있는 코드를 짜라는식의 말을 많이 들었다.

변수, 메서드의 이름만으로 이해할 수 있는..

거짓말은 잘해봤어도 글짓기는 잘 못했었는데.. 이름짓기 참 힘들더라능~ -_- 쿨럭;;

여튼; 나름 junit을 이용해서 테스트 주도 개발!을 하고 있고!! 많이 익숙해져있는 지금..!

다른 유명하신분들 블로그 기웃거리다 보니 Hamcrest 라는게 TestCase 코드에 보이더라..

그 코드들.. 하나하나 조목조목 유심히 살펴보면 정말 직관적인것 처럼 보인다.

구글링 하다보니 이런 코드가 있던데.. 사용해본적이 없어서 맞는 문법인지는 모르겠다.

    @Test
    public void should_find_embedded_search_term_at_start() {
        List<Stakeholder> stakeholders  = stakeholderManager.findByName("Health");
        assertThat(stakeholders, hasItem(hasProperty("name",is("Health Associates"))));
    }

대충 내용은..

' health라는 stakeholder 리스트를 가져온다, 그 중 name이 Health Associates인 프로퍼티를 가지고 있는 객체가 있나? '

뭐 이런 테스트를 하는것 같다.

더 복잡한 케이스도 있었는데 직관적?.. 글세 눈에 안들어오더라;;

-_-;; 해보지 못해서 설명이 안되는것 같다...;;

이렇게 해봤다.. 좋은 개발자는 구글 검색도 잘한다던데....--;; 참 힘들게 테스트 케이스 하나 성공시켜봤다;

내 나름대로 해석은..

' person리스트 요소중에서 'name'이 'minato0'인 property를 가지고 있는 person이 있느냐.. ' 였다.

확실히 Loop를 돌리지 않고 저런식으로 Collection 요소를 검색하는 방법, 은근 좋긴 하다.

걱정은 Hamcrest를 사용하면, 나 외에 다른 사람들이 테스트 코드를 봤을때 거부감이 생기진 않을지,

시간을 들여 공부, 적용, 적응 해볼만한건지.. 흠....

이번엔 다른 예제로 writeReplace와 readResolver를 사용해보자..

얕은 지식으론 설명에 한계가 있기 때문에 그냥 이럴때 이렇게 사용한다더라.. 정도의 상황 설명이....

다음과 같은 Json객체를 직렬화 하려고 한다. 물론 설명을 위해 억지로 만들어진 객체이다 - -;;

앞서 Person객체를 직렬화 했던 방법과 동일하다. 그러나.......

테스트는 통과하지 못하고..

Json객체가 필드로 가지고 있는 JsonObject객체를 직렬화 할수 없다는 예외가 발생한다.

JsonObject객체는 Serializable를 구현하지 않은 객체라서 직렬화 할수 없었다.

물론 필드를 직렬화에 포함시키지 않는 방법이 있다.

 * 참고 - private transient JsonObject jso;

암튼, 미션은 JsonObject도 함께 직렬화를 해야한다는 것인데.. (수석님이 여러가지 꼼수들을 보여주셨지만 그건 패스하고...- -;;)

writeReplace와 readResolve를 사용해서 해결한다.

writeReplace 할때 Proxy객체를 하나 정의해서 jsonString을 잠시 보관하고 Proxy객체를 리턴한다.

그리고 읽어올땐 Proxy객체에 정의된 readResolve를 통해 다시 Json객체를 생성해서 리턴한다.

둘다 리턴되는 값은 Serializable를 구현한 객체만 가능하다.

상당히 간단한 예제였기 때문에 쉬워보일수도 있는데 좀 덩치큰 객체들이 직렬화 될때를 상상해보면 저런 후킹 메서드들을 어떻게 잘 사용할수 있을지 걱정이 된다......

우리 수석님께서 예제를 주시며 직렬화 해보라는 미션과 직렬화에 대한 질문을 하셨다......T^T

사실 직렬화를 해본적이 없어서 설명하기가 상당히 난해했다.

교육기관이나 책같은걸 보면 객체 자체를 파일에 쓰고.. 다시 역직렬화해서 읽어오는 예제가 많다.

그래서 직렬화라는게 그게 다인줄 알았다...- -;

사실 난 모르는게 너무 많고 어설픈 개발일을 하고 있다보니 이런 고급 기술을 쓸 기회가 없어서 나중에 진짜 개발자가 되었을때 써먹기 위해 포스팅 해본다..

이런 Person 클래스가 있고, 

이것을 직렬화 하려면 이런식으로 한다.

보통 예제들은 파일에 쓰고 다시 파일을 읽어다가 객체로 만드는데 여기선 그냥 잠깐 Byte배열로 저장했다가 다시 그 바이트를 읽어다가 객체로 만들었다.

암튼, 이게 일반적으로 알고있는 직렬화 라는거였다. (이건 나도 해봤어!)

물론, TestCase도 통과했다.

다음으로 Person객체에 몇가지 메서드를 정의해본다.

다시 테스트 실행을 해보면,

두둥!! 방금 Person객체에 정의한 메서드들이 위와 같은 순서로 실행됬다. 물론 테스트는 실패했을꺼다~

정확한 설명은 어렵지만 직렬화를 할때 JVM이 저런 메서드를 잡아서(?) 실행하는것 같다.......

후킹 메서드라 해야할까.. (용어 지식도 딸림....)

아무튼 이중에 writeObject와 readObject를 사용해서 테스트를 통과시키려면... 자알~ 구현을 해야한다..

이런식으로 구현할수 있고, 사실 위 예제는 불필요하게 구현을 하지 않아도 되잖아?!

좀 더 복잡한 객체, 혹은 어떠한 제약조건이 있을시에 언젠가 분명 사용할 날이 올것이다.

다음편....