ActiveMQ 메모ActiveMQ 메모
Posted at 2010. 9. 10. 16:08 | Posted in OpenSource- queue 최대값(the maximum number of matched messages)을 지정해 놓았을 때, 최대값에 다다르면 오래된 것이 discard 된다?
- prefetch size, pending limit 등 조절하여 메시지 discard가 있는지 확인해 보자. 위의 글로는 메시지가 discard되는 것으로 보이나, 문맥상 consumer에 prefetch될 메시지를 discard한다는 뜻 같기도 함.(영어 실력이 딸려서..)
- PendingMessageLimitStrategy를 사용할 수 있으며, 다음과 같이 설명하고 있다.
You can configure the PendingMessageLimitStrategy implementation class on the destination map so that different regions of your topic namespace can have different strategies for dealing with slow consumers. For example you may want to use this strategy for prices which are very high volume but for orders and trades which are lower volume you might not wish to discard old messages.
The strategy calculates the maximum number of pending messages to be kept in RAM for a consumer (above its prefetch size). A value of zero means keep no messages around other than the prefetch amount. A value greater than zero will keep up to that amount of messages around, discarding the older messages as new messages come in. A value of -1 disables the discarding of messages.
So ActiveMQ uses a prefetch limit on how many messages can be streamed to a consumer at any point in time. Once the prefetch limit is reached, no more messages are dispatched to the consumer until the consumer starts sending back acknowledgements of messages (to indicate that the message has been processed). The actual prefetch limit value can be specified on a per consumer basis.
Its a good idea to have large values of the prefetch limit if you want high performance and if you have high message volumes. If you have very few messages and each message takes a very long time to process you might want to set the prefetch value to 1 so that a consumer is given one message at a time. Specifying a prefetch limit of zero means the consumer will poll for more messages, one at a time, instead of the message being pushed to the consumer.
Pooled Connections and prefetch
Consuming messages from a connection pool can be problematic due to prefetch. Unconsumed prefetched messages are only released when a connection is closed, but with a pooled connection the connection close is deferred (for reuse) till the connection pool closes. This leaves prefetched messages unconsumed till the connection is reused. This feature can present as missing or out-of-sequence messages when there is more than one connection in the pool.
One solution is to use pooled connections for producers and a non-pooled connection for consumers. This might have performance impacts on the consumer side, if multiple threads try to consume messages at a fast rate. Alternatively, reduce the pool size to 1 for consumers. A third alternative is to reduce the prefetchSize to 1 or 0 with the pooled connection factory. When using Spring JMS and MessageDrivenPojo, you cannot use a prefetch of 0, so use 1 instead.
- The ActiveMQ broker auto-creates the physical resources associated with a destination on demand.
- broker가 시작할 때 미리 만들어 둘 수도 있다. http://activemq.apache.org/configure-startup-destinations.html
- 클라이언트에서 destination을 만들었다고 해서 서버에 만들어 지는 것은 아니다. 해당 큐 또는 토픽으로 메시지가 들어오면 만들어진다. 따라서 클라이언트가 destination 객체를 많이 만들었다고 해서 서버의 리소스를 사용하지 않는다.
- Exclusive Consumer - http://activemq.apache.org/exclusive-consumer.html
- 요약하면 queue에 하나의 consumer만 붙게하는 것.
- queue:consumer=1:1 을 broker가 보장해준다.
- Message Group - http://activemq.apache.org/message-groups.html
- Parallel Exclusive Consumer 같은 것.
- 메시지가 어떤 그룹에 속하지는 구분하기 위해 표준 JMS 헤더는 JMSXGroupID 를 사용.
- 같은 그룹은 같은 consumer에게 가는 것을 보장한다. consumer fail시 다른 consumer가 선택된다.
- 그룹 ID를 HTTP session ID에 비유하면 broker는 HTTP load balancer가 된다.
- broker는 메시지가 들어오면 그룹 ID를 검사하고, 해당 그룹에 연결된 consumer가 있는지 확인하여 전달.
- hash를 사용하므로 많은 수의 그룹을 사용할 수 있다. (Since there could be a massive number of individual message groups we use hash buckets rather than the actual JMSXGroupID string)
- consumer는 자신이 close되거나 외부에서 그룹을 close할때까지 메시지를 받는다.
- Getting notified of ownership changes of message groups: 네트워크 오류 등으로 failover처리가 되는 경우 consumer가 변경될 수 있는데, 이 때 consumer는 특정 메시지 그룹의 메시지를 처음 받는 것인지 확인 할 수가 있다. JMSXGroupFirstForConsumer boolean값을 확인하면 된다. consumer가 가진 캐시나 자원을 초기화 하는 작업 등을 할 수 있다.
- Adding new consumers: consumer들이 모두 연결되지 않은 상태에서는 첫번째 consumer가 모든 그룹의 메시지를 처리하려고 할 것이다. 이 상황을 피하기 위해 destination policy에서 consumersBeforeDispatchStarts 와 timeBeforeDispatchStarts 를 사용할 수 있다. 모든 consumer가 연결될 때까지 dispatching을 지연시킨다.
☞ consumer는 메시지 그룹별로 타이머를 걸어 특정 시간 이후로 메시지가 없을 때 그룹 close를 시키면 부드럽게 load balancing이 될 것이다.
www.deepblue.pe.kr
