2011-10-04 16 views
5

Cercare aiuto per la configurazione di SystemUsage e destinationPolicy poiché sto riscontrando qualche difficoltà nella completa comprensione della relazione tra systemUsage, destinationPolicy e controllo di flusso.ActiveMQ destinationPolicy e systemUsage Configuration

Tutti i nostri messaggi sono persistenti! producerFlowControl è attivo.

Quindi diamo ad ActiveMQ un massimo di 512 MB di spazio heap.

nostro systemUsage è impostato come di seguito:

<systemUsage> 
    <systemUsage> 
     <memoryUsage> 
      <memoryUsage limit="200 mb"/> 
     </memoryUsage> 
     <storeUsage> 
      <storeUsage limit="10 gb"/> 
     </storeUsage> 
     <tempUsage> 
      <tempUsage limit="1000 mb"/> 
     </tempUsage> 
    </systemUsage> 
</systemUsage> 

La nostra politica di destinazione come di seguito:

<destinationPolicy> 
    <policyMap> 
     <policyEntries> 
     <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb"> 
      <pendingSubscriberPolicy> 
      </pendingSubscriberPolicy> 
     </policyEntry> 
     <policyEntry queue=">" producerFlowControl="true" memoryLimit="1mb"> 
     </policyEntry> 
     </policyEntries> 
    </policyMap> 
</destinationPolicy> 

Qualcuno può verificare se la seguente è corretto:

Ciò significa che per ogni coda/argomento individuale il limite di memoria è 1 MB. Che cosa succede esattamente quando viene colpito questo 1 MB, il blocco della coda per i produttori o lo fa su disco?

La memoria totale consentita per tutte le code e gli argomenti è 200 MB. Significa che potremmo avere 200 canali che funzionano alla loro piena capacità di 1 MB. Attualmente abbiamo 16 code e argomenti in totale, quindi ovviamente non viene mai raggiunto.

È meglio rimuovere la voce di criterio individuale sul limite di memoria e condividere la memoria tra i vari canali?

Se lo facciamo, a che punto bloccerebbero?

Qualsiasi aiuto molto apprezzato! Puoi paypal un po 'di soldi della birra!

risposta

6

Stai toccando un certo numero di punti qui, che risponderò fuori servizio.

memoryUsage corrisponde alla quantità di memoria assegnata all'archivio in memoria. storeUsage corrisponde a quanto spazio deve essere dato al negozio KahaDB. O usi l'uno o l'altro, a seconda di come vuoi che il tuo broker mantenga i messaggi o meno. tempUsage è un caso speciale per i cursori di file (http://activemq.apache.org/message-cursors.html) - un meccanismo per traboccare la memoria dall'archivio in memoria su disco se viene superato il limite di memoria (devi configurare questo comportamento a livello di destinazione, se lo si desidera).

policyEntry @ memoryLimit è un sub-limite per le singole destinazioni.

Ciò che accade quando si superano i limiti di memoria dipende dall'attivazione del controllo di flusso del produttore (PFC). È attivo per impostazione predefinita per le code, disattivato per argomenti e invia asincroni alle code; tutto questo può essere configurato in policyEntry (http://activemq.apache.org/per-destination-policies.html).

Se si attiva un "limite di memoria" quando PFC è attivo, i client bloccano finché qualcuno non libera spazio consumando messaggi dallo store. Se è disattivato, l'invio genererà un'eccezione (migliore è la caduta del client rispetto al broker). "Limite di memoria" indica o quello definito da memoryUsage su tutte le code, o il limite specifico della coda (è possibile colpire il primo prima di quest'ultimo).

Se si desidera o meno un limite specifico di destinazione dipende dal proprio caso d'uso. Suggerirei di ignorarlo a meno che tu non stia cercando di ottenere un risultato specifico.

+0

Come nota, se si raggiunge un limite di memoria, la coda appare anche "vuota" ai consumatori transitati, fino a quando qualcun altro libera spazio. Inoltre, i cursori sono utili solo fondamentalmente per "memorizzazione di messaggi non persistenti se si esaurisce il limite di memoria", giusto? – rogerdpack