BlazeDS+Spring+activeMQ outofmemory

1. BlazeDS 메모리 오버플로우 수정안:
BlazeDS는 빅데이터 양, 데이터 전송 빈번, 페이지 리셋이 빈번하고 서버session 시간이 너무 긴 경우 메모리 유출을 초래할 수 있습니다.http 프로토콜은 무상태이기 때문에 클라이언트가blazeds에게 주동적으로 알리지 않는다.blazeds는 클라이언트가 끊어진 것을 모르고 세션이 시간을 초과할 때까지 기다린다. 그리고 클라이언트가 서버를 연결할 때마다 FlexClient가 생기고 FlexClient 대상은 하나의 메시지 대기열을 유지하기 때문에 이 문제를 해결하려면 두 곳에서 시작해야 한다. 클라이언트와 서버.
1. flex 사이드 코드 수정(링크 자동 닫기)
(1)
//페이지 종료 이벤트 감청

var connectManager:MessageConnectManager = MessageConnectManager.getInstance();
connectManager.regist();
connectManager.addEventListener(MessageConnectManager.DISCONNECT,disConnectHandler);

//페이지 비활성화 링크 닫기

protected function disConnectHandler(e:Event):void
{
if(this.consumer && this.consumer.channelSet){
this.consumer.channelSet.disconnectAll();
}
}

2, blazeDS 프로필 수정(네트워크가 끊기거나 사용자가 페이지를 자주 새로 고쳐 메모리 유출)
프로필 flex-services-config를 수정합니다.xml :

<channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel">
            <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
            <properties>
                .....(2)
<flex-client-outbound-queue-processor   class="processor.TimeoutOutBoundQueueProcessor">
<properties>
<!--message time out  in millisecond-->
<messageTimeOut>30000</messageTimeOut>
<!--client time out in millisecond-->
<clientTimeOut>12000</clientTimeOut>
</properties>
</flex-client-outbound-queue-processor>
            </properties>
        </channel-definition>
 
 
<channel-definition id="my-longpolling-amf" class="mx.messaging.channels.AMFChannel">
 
<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amflongpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
 <properties> 
                .....(3)
<flex-client-outbound-queue-processor   class="processor.TimeoutOutBoundQueueProcessor">
<properties>
<!--message time out  in millisecond-->
<messageTimeOut>30000</messageTimeOut>
<!--client time out in millisecond-->
<clientTimeOut>12000</clientTimeOut>
</properties>
</flex-client-outbound-queue-processor>
     </properties>
</channel-definition> 

둘째, activeMQ 메모리 넘침 수정 방안:
acitve MQ는 5.4 버전 이후에 느린 소비자를 처리할 수 있습니다. 예를 들어blazeds+spring+activemq가 통합될 때 모든 클라이언트가blazeds와 링크를 끊으면,activemq는spring JMSAdapter에 데이터를 계속 발생시키고spring JMSAdapter가 메시지를 받은 후에 메시지 대기열에 넣고activemq에 알리지 않아 메모리가 넘칩니다.
activemq 프로필 수정

<broker xmlns="http://activemq.apache.org/schema/core"
brokerName="messagebus" dataDirectory="activemq/data"
destroyApplicationContextOnStop="true" persistent="true">
<destinationPolicy>
<policyMap>
<policyEntries> 
      ........(4)
           <policyEntry topic=">" producerFlowControl="false" memoryLimit="1mb" topicPrefetch="100" >
<slowConsumerStrategy>
    <abortSlowConsumerStrategy checkPeriod="30000" maxSlowDuration="120000" abortConnection="false" />
</slowConsumerStrategy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
.......(5)
<systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="20 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="1 gb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="100 mb"/>
                </tempUsage>
            </systemUsage>
        </systemUsage>
</broker>

구성 설명:
(1): 클라이언트가 beforeunload 이벤트를 감청하고 링크를 끊습니다.도구 클래스는 첨부 파일 "MessageConnectManager.as"를 참조하십시오.
(2)(3): 서버 측 보호 조치, 첨부 파일 "TimeoutOutBoundQueue Processor.java"
messageTimeOut: 대기열의 메시지 시간 초과 시간, 단위 밀리초, 지정된 시간을 초과하여 대기열을 제거합니다.
client Time Out: 클라이언트의 시간 초과 시간, 지정된 시간을 초과하면blazeDS가 클라이언트flush 데이터에 대한 데이터가 없습니다. 클라이언트가 링크를 끊었음을 의미합니다. 현재 테스트blazeds의 최대 flush 시간 1분입니다.
(4): activeMQ 느린 소비자 처리 전략
topicPrefetch: 소비자가 받았지만 응답하지 않은 대기열 길이, 이 길이를 초과하면 mq는 이 소비자에게 데이터를 전송하지 않습니다
slowConsumerStrategy: 느린 소비자 정책(소비자가 느린 것을 어떻게 평가합니까? 지정된 시간 내에 응답하지 않은 메시지의 길이가 topicPrefetch 설정에 도달하거나 느린 횟수에 도달했습니다. 현재 전자를 사용하고 있습니다)
checkPeriod: 소비자의 느린 빈도 확인
maxSlowDuration: 느린 지속 시간
abortConnection: 링크 중단 여부(중단할 수 없음 주의)
(5): activeMQ는 시스템 자원 제한을 차지하고 제한을 초과하여 디스크로 지속됩니다.