Hazelcast conta divisorie e concorrenza thread

Question

Nel Master Hazelcast eBook sotto "Operazioni di partizione-aware 17.4.1" si legge:

Per eseguire le operazioni di partizione-aware, si crea una serie di fili di funzionamento.

Un singolo thread di operazioni esegue operazioni per più partizioni;

Ogni partizione appartiene a una sola operazione.

Supponiamo di avere il numero predefinito di 271 partizioni su un cluster a 17 nodi ciascuno con 16 thread di partizione. Distribuendo le partizioni attraverso il cluster, questo significa che tutte le partizioni avranno un thread associato e ogni thread avrà solo 1 partizione (mi sembra il caso ottimale).

Ignorando i backup e le cache vicine, quando creo un'istanza IMap, significa che posso sempre eseguire 1 operazione put/get simultanea su ogni partizione di mappa attraverso il cluster? Andando oltre, se collego un MapStore, significa che posso sempre avere 271 operazioni concorrenti in esecuzione sul mio database di back-end, dato che non c'è modo di creare MapStore asincroni?

Il motivo per cui ho chiesto questo è che ho un'applicazione web estremamente concorrente e di recente ho cambiato l'archivio dati per eseguirlo con Hazelcast IMap. L'applicazione accetta migliaia di connessioni simultanee e quasi ogni singola richiesta esegue almeno un'operazione get dalla mappa distribuita. Sto vedendo un sacco di questi errori:

com.hazelcast.core.OperationTimeoutException: No response for 20000 ms. Aborting invocation! Invocation{serviceName='hz:impl:mapService', op=com.hazelcast.map.impl.operation.GetOperation{identityHash=1003806362, serviceName='hz:impl:mapService', partitionId=244, replicaIndex=0, callId=55212219, invocationTime=1462913274676 (Tue May 10 20:47:54 UTC 2016), waitTimeout=-1, callTimeout=10000, name=..., name=...}, partitionId=244, replicaIndex=0, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeout=10000, target=Address[10.0.2.221]:5701, backupsExpected=0, backupsCompleted=0, connection=Connection [/10.0.2.219:5701 -> /10.0.2.221:14565], endpoint=Address[10.0.2.221]:5701, alive=true, type=MEMBER} No response has been received! backups-expected:0 backups-completed: 0

Questo potrebbe semplicemente essere causato dal MapStore bloccare il thread partizione mentre si sta cercando di recuperare dal database? Dovrei anche notare che mentre dice No response for 20000 ms, 20s non è scaduto.

Io corro Hazelcast 3.6.2 su Java 8.

Answer 1

backup gnoring e vicino-cache, quando creo un'istanza iMap, questo significa che posso sempre e solo avere 1 put concomitante/ottenere l'operazione in esecuzione su ogni partizione della mappa attraverso il cluster?

Corretto. Quindi potrebbe essere che la partizione 25 della mappa ae la mappa b, sia occupata a elaborare un'operazione per la mappa b e quindi un'operazione per la mappa a deve attendere.

Andando oltre, se allego un MapStore, questo significa che può sempre e solo avere 271 operazioni simultanee in esecuzione contro il mio database di back-end, dal momento che non v'è alcun modo di fare MapStores asincrone?

Per una scrittura tramite mapstore -> sì. Ma io non sono quel familare con il modello di threading delle mapstore (asincrono).

Questo potrebbe semplicemente essere causato dal MapStore bloccare il thread partizione mentre si sta cercando di recuperare dal database? Dovrei anche notare che mentre non dice alcuna risposta per 20000 ms, 20 secondi non sono scaduti.

Questa potrebbe essere la causa.