원문 주소 : http://fiaa.net/aqua/archives/244 

하지만 페이지로 접속이 되지 않아 구글 저장 페이지를 열어 보았습니다.

http://webcache.googleusercontent.com/search?q=cache:YaaoufhV-UYJ:fiaa.net/aqua/archives/244+&cd=1&hl=ko&ct=clnk&gl=kr&lr=lang_ko

자바메일로 IMAP 폴더 사이즈 계산이 느린 이유

메일이 52,630통 정도 되는 INBOX가 있다.
개별 메일의 사이즈는 945bytes 정도 된다.

자바메일로 folder size를 요청하면 대략 1분 정도가 소요된다.
하지만 펄로 folder size를 요청하면 4~5초 정도가 소요된다.

둘의 차이는?
당연히 라이브러리에서 IMAP Query 차이가 자바가 느리게 실행된 이유다.

먼저 에서 날린 쿼리를 보자.

1 LOGIN username password
2 EXAMINE INBOX
3 UID SEARCH ALL
4 UID FETCH 145,147:183,186,190:194,197:244,251:253,256:52785,52806:52810 (RFC822.SIZE)

다음으로 자바에서 날린 쿼리를 보자.

A1 LOGIN username password
A2 CAPABILITY
A3 LIST “” INBOX
A4 EXAMINE INBOX
A5 FETCH 1 (ENVELOPE INTERNALDATE RFC822.SIZE)
A6 FETCH 2 (ENVELOPE INTERNALDATE RFC822.SIZE)
A7 FETCH 3 (ENVELOPE INTERNALDATE RFC822.SIZE)


A52640 FETCH 52810 (ENVELOPE INTERNALDATE RFC822.SIZE)

[차이점 1]
FETCH명령을 사용하는 방법이 다르다.
펄은 연속된 UID는 147:183 이런식으로 쿼리를 사용했지만,
자바는 UID 마다 각각의 쿼리를 날렸다.

[차이점 2]
FETCH 명령을 쓸 때 옵션이 다르다.
펄에서는 RFC822.SIZE만 쓴 반면에 자바에서는 ENVELOPE INTERNALDATE까지 썼다.
사이즈만 계산하는데 굳이 ENVELOPE INTERNALDATE를 붙일 필요가 없다.

[결론]
1. 자체 라이브러리를 만들어야 한다.
2. 자바메일은 잘못된 IMAP Query 방법 때문에 서버의 불필요한 IO만 증가 시켜서 처리 속도를 느리게 했다.

Posted by 오달봉
,

이글은 테이블 스페이스가 날아가고 해당 데이터 베이스를 복구하지 않는다는 전제하에 쓴 글이다.

안쓰는 DB서버에 실수로 테이블 스페이스 파일 (dbf파일)을 날리고 서버에서

ora-01034 ORACLE not availableORA-27101 요딴 메세지나 나온다.

아무리 개발연차가 늘어도 DB서버에서 문제가 나면 작아지는 기분이다.

방법은 이렇게

ALTER DATABASE DATAFILE '{dbf파일}' OFFLINE DROP;
ex) ALTER DATABASE DATAFILE '/home/oracle/db_files/workflow.dbf' OFFLINE DROP;

RECOVER DATABASE;

alter database open;

이런식으로

이런 후 oracle을 내렸다가 다시 올린다.

다들 알겠지만 그래도 내렸다가 올리는 법은

shutdown immediate;

startup;

이러니깐 잘 되더라~~~ ㅋㅋㅋ 

Posted by 오달봉
,

본인이 재직중인 핸디소프트에는 다양한 제품들이 존재한다. 이중 현재 회사에서 주력하고 있는 제품이 SNS인데

전부터 열풍이 불던 SNS열풍의 후광을 업고 기업 소셜네트워크 구축에 일조를 하고 있다.

그런데 한가지 아쉬운건 유용한 기사나 블로그의 주소를 붙여 넣으면 페이스북 처럼 썸내일과 기사 요약을 보여주는 기능이 누락되어 있었다. 그래서 사내 이런 기능을 요청하였는데 겁없이 간단히 구현 할 수 있을꺼란 말을 넣어버렸다. ㅜㅜ

내 생각으론 간단할꺼 같은데 실제 구현단으로 들어가면 이래저래 예외가 발생할 수 있기 때문에 많은 부분을 고려해야 할 지도 모른다. 


요딴 식으로 올렸는데 정말 구현이 쉬울지는 나도 한번 겪어봐야 알겠다는 생각이 들었다. 그래서 봄날의 오후 근처 스타벅스에 들려 노트북을 이용해 공부도 해 볼 겸 겸사겸사 한번 구현해 보기로 했다.

1. 분석

페이스북에서 제공하는 요약의 이미지는 다음과 같으며 분석해본 결과는 다음과 같다.


1. 처음에 보이는 링크는 해당 기사의 title태그를 가져와 url을 링크로 걸었다.
2. www.bloter.net은 해당 사이트의 대표 url이다.
3. 본문 내용은 해당 웹페이지에 있는 contents라는 아이디의 div내의 text를 가져왔다.
4. 좌측은 썸내일은 아이디 contents내에 있는 img태그들중 첫번째 이미지이다.

재밌는점은 해당 샘플페이지인 블로터 닷넷외에도 티스토리 이글루스 그외 언론사이트 역시 해당 룰데로 페이스 북에서 데이터를 파싱하고 있다는 점이다. (무슨 규약인지 아시는 분은 댓글 좀 부탁 드릴께요 ㅜㅜ rss관련 뭔가인가?)

 이런 전제로 내가 구현할 로직에 대해서 구체화를 하였다.

1. 아파치 common library 중 HttpClient패키지를 사용해 웹의 본문 데이터를 가져온다.
2. Jsoup으로 해당 페이지를 파싱하여, 요구사항에 언급된 내용을 데이터화한다. (물론 jsoup에서 connect메소드를 사용하여 본문 내용을 긁어 올수 있다. 걍 여러 라이브러리 써보는 연습차 1번 사항을 추가로 했다. 비효율적인거 나도 안다. ㅋㅋㅋ )

두가지 룰을 지키기로 하고, 이 포스트에서 자바 로직단 만을 보여주기로 한다. 하지만 전체적인 플로우는 다음과 같을 꺼라 생각한다.

1. 클라이언트에서 주소 붙여넣기 이벤트 혹은 url타이핑이 감지되면 ajax를 이용하여 해당 기사의 요약을 생성하는 로직을 요청(파라미터는 url)
2. 서버에서는 해당 url을 이용해 데이터를 프로세싱 결과값을 콜백(json형태로 리턴)
3. 클라이언트는 콜백받은 데이터를 이용해,  웹화면을 구성한다.

웹을 개발하는 사람들에게 1,3번은 어렵지 않은 부분으로 2번에 대해 소스코드를 구현해보자. 간단히 테스트 형태의 구조이며, 예외처리를 따로 감안하지는 않았다.

1. 먼저 이클립스를 이용해 apache common라이브러리와 jsoup라이브러리를 import한다. 내가 포함한 라이브러리는 이미지를 참고 부탁한다.(commons-httpclient-3.0.1이 실제적인 라이브러리지만 해당 jar는 logging과 codec에 대한 의존성을 가지고 있으며, jsoup은 html 파싱라이브러리이다. css 셀렉터를 활용할 수 있어, jquery에 익숙한 사람들에게는 유용한 라이브러리이다. 마치 python의 beautiful soup을 연상쾌 한다.)

 


2. 메인 함수에서 순서를 정리한다.(이미지 형태로 보여드립니다. 소스코드를 첨부하오니 복사& 붙여넣기는 하단에 첨부된 소스코드를 이용해 주세요.)

3. downloadContent 메소드는 웹에서 본문을 가져오기 위해 사용되는 메소드이며 다음과 같이 구현한다.

4.  downloadContent메소드에서 가져온 내용을 바탕으로 parseDate메소드에서 요약에 필요한 내용을 만든다. 보시는 바와 같이 jsoup은 jquery셀렉터와 같이 html엘리먼트들을 파싱해 낼 수 있다. (참고로 본문 내용을 요약한다는 가정하에 전체문장에서 100자만 짜른다. 그리고 이미지들을 다양하게 구성할 수 있어 대표이미지 하나가 아닌 배열 형식으로 전체를 저장하는 방법을 선택하였음.)

5. 이것대로 구성하여 본문을 만들면 다음과 같은 결과가 출력될 것이다.

이 데이터를 response단에 넣으면 될 것이다. 자세한 것은 첨부한 소스코드를 확인해 보길 바란다.

하나는 해당 내용에 대한 순수자바 파일이고 다른 하나는 바로 이클립스에서 넣고 확인해 볼 수 있는 이클립스 project 압축 파일이다.



ArticleTest.java


test.zip


Posted by 오달봉
,