(자바) 개발자가 놓치기 쉬운 자바 기본원리(강추)
참고: http://roughexistence.tistory.com/141
글
(애플리케이션개발) 개발일지
*AMQP, MQTT, STOMP 비교글 http://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.html *JMS는 자바 EE환경에서 메시징을 보내는 가장 먼저 떠오르는 환경이지만 톰캣 설치에 라이브러리를 추가해야 하고 톰캣 구성을 광범위하게 수정해야 하기 때문에 톰캣과 같은 서블릿 전용 컨테이너나 독립형 애플리케이션에서는 구성하기가 아주 까다롭다는 문제점이 있다. *처음에는 객체를 전송하기 위해서 Serializable를 이용했지만 Parcelable로 바꿔서 객체를 전송시키니 속도가 증가, 그 이유는 개발자가 직접 세팅을 하기 때문이다. *세션유지, 쿠키설정 중요하게 여길것(자동로그인) *개인정보를 수정하는 부분은 전부 Interceptor로 세션유지를 확인한다. *서버로부터 개인 프로필 이미지를 가져올때( 이미지는 MySQL에 서버에 저장해 둔다??????) -->디비서버에는 이미지에 대한 메타정보만 저장해둔다.( -->별도의 이미지 서버를 구축해둔다. ->이떄 이미지 URL을 저장해둔다.이유는: 이미지를 통해 의사소통이 이루어지기 때문에 이미지 서버를 분산시켜야 한다.(아마 memchached사용) ->확장성 있는 시스템을 설계하기 위해 명확한 인터페이스를 기반으로했다. -->이미지 메타데이터를 칼럼에 저장하기 위해서 Char, VARCHAR 의 선택시 고려한것은, 1. 가변길이인가? 2. 칼럼의 값이 자주변경되는가? <8월23일 할 것> 1. 현재 친구 추가를 했음.Friend_ListViewActivity에서 친구추가 후 친구추가를 실시간으로 갱신해주는 것이 필요함 <8월26일> 1. 서버로 부터 받아온 친구들의 이름, 사진은, 유저의 임베디드 SQL에 저장시킨다.(이때 DBHandler가 이 모든 것을 컨트롤한다.) -->사...
(RabbitMQ) 라우팅키에 대한 경험
*Exchange에서 Topic또는 direct를 사용할 경우 Routing Key를 명시한다. 만약 amq.topic이라는 Exchange를 사용하여 chat큐에 메시지를 전송할 경우 클라이언트의 Publish측에서는 basicPublish("amq.topic","chat",null,바이트내용); 으로 보내주면 된다.(단, 이경우 amq.topic이라는 Exchange가 rabbitmq서버에 만들어져있는 경우이다. 없다면 Exchange를 만들어 주어야 한다.) 이는 amq.topic에서 chat라는 라우팅키를 가지는 메시지를 전송한다는 의미이다. 그렇다면 Consumer측에서는 어떻게 수신할까? 이 부분에서 상당히 본인의 경우는 많은 시간을 할애해야 했다...... 클라이언트측에 Consumer에서는 channel.queueBind(q.getQueue(), "amq.topic" , "#.chat" ); 이런식으로 만들었는데, 이는 Consumer인 내가 amq.topic이라는 exchange로 부터 오는 "#.chat"라는 라우팅키를 가지고 있는 (즉, Publish에서 .chat로 끝나는 라우팅키로 전송한것) 메시지를 channel과 연결되어있는 queue로 부터 받겠다. 라는 의미이다. 만약 그런 큐가 존재하지 않으면 임의로 rabbitmq서버 측에서 생성해버린다. 그 이유는 분명히 chat라는 큐가 존재하고 "chat" 라우팅키로 연결되어 있었다. 하지만 저 문장을 다시 실행해보니 chat라는 큐에 #.chat라는 라우팅키를 가지는 통로가 새로 생겼다. 즉, 메시지를보내는 입장에서는 메시지의 내용과 Exchange와 라우팅키만 신경쓰면되는것이다. 메시지를 수신하는 측은 라우팅키와 Exchange만 신경쓰면된다. 또한 중요한 점은 메시지를 수신하는 측은 수신측 마음대로 큐를 생성해도 된다. ...
(트러블슈팅) RabbitMQ Exchange-Exchange Binding 문제
문제점은 Exchange binding을 chat와 messageToClient와도 하고 chat와 messageToServer이랑도 하였다. 즉 3개의 Exchange가 바인딩된 것이다. 이렇게 바인딩하고 chat에서 topic타입으로 메시지를 전송하면 전송이 되지 않는다. 아마 최대 2개의 Exchange가 연속으로 붙어있는 바인딩만 되는 것같다.
(데이터베이스) 결합알고리즘의 성능(NestedLoop, Hash, SortMerge)
*NestedLoop가 효율적으로 작동하지 않는 경우의 차선책은 Hash이다. <Hash의 특징> 결합테이블로부터 해시테이블을 만들어서 활용하므로, NestedLoop에 비해 메모리를 크게 소모한다. 메모리가 부족한 경우 저장소를 사용하므로 지연이 발생한다. 출력되는 해시값은 입력값의 순서를 알지 못하므로, 등치 결합에만 사용할 수 있다. <Hash가 유용한 경우> NestedLoop에서 적절한 구동테이블(상대적으로 충분히 작은 테이블)이 존재하지 않는 경우 앞서 'NestedLoop의 단점에서 본것처럼 구동테이블로 사용할만한 작은 테이블은 있지만, 내부 테이블에서 히트되는 레코드 수가 너무 많은 경우 NestedLoops의 내부테이블에 인덱스가 존재하지 않는 경우(또는 여러가지 사정에 의해 인덱스를 추가할 수 없는) 경우