Risolvere i problemi relativi al processore di eventi Hub eventi di Azure

Questo articolo fornisce soluzioni ai problemi comuni che possono verificarsi quando si usa il EventProcessorClient tipo. Se si stanno cercando soluzioni ad altri problemi comuni che possono verificarsi quando si usa Hub eventi di Azure, vedere Risolvere i problemi Hub eventi di Azure.

412 errori di precondizione quando si usa un processore di eventi

412 errori di precondizione si verificano quando il client tenta di acquisire o rinnovare la proprietà di una partizione, ma la versione locale del record di proprietà non è aggiornata. Questo problema si verifica quando un'altra istanza del processore ruba la proprietà della partizione. Per ulteriori informazioni, vedi la sezione successiva.

Modifiche frequenti alla proprietà della partizione

Quando viene aggiunto o rimosso il numero di EventProcessorClient istanze, ovvero vengono aggiunte o rimosse, le istanze in esecuzione tentano di bilanciare il carico delle partizioni tra loro. Per alcuni minuti dopo il numero di modifiche apportate ai processori, è previsto che le partizioni modifichino i proprietari. Dopo il bilanciamento, la proprietà della partizione deve essere stabile e cambiarne raramente. Se la proprietà della partizione cambia spesso quando il numero di processori è costante, è probabile che indichi un problema. È consigliabile segnalare un problema di GitHub con i log e una procedura di riproduzione.

La proprietà della partizione viene determinata tramite i record di proprietà in CheckpointStore. In ogni intervallo di bilanciamento del carico, EventProcessorClient eseguirà le attività seguenti:

1. Recuperare i record di proprietà più recenti.
2. Controllare i record per visualizzare i record che non hanno aggiornato il timestamp entro l'intervallo di scadenza della proprietà della partizione. Vengono considerati solo i record corrispondenti a questi criteri.
3. Se sono presenti partizioni non rilevate e il carico non è bilanciato tra le istanze di , il client del processore di EventProcessorClienteventi tenterà di richiedere una partizione.
4. Aggiornare il record di proprietà per le partizioni di cui è proprietario che dispone di un collegamento attivo a tale partizione.

È possibile configurare gli intervalli di scadenza del bilanciamento del carico e della proprietà quando si crea EventProcessorClient tramite EventProcessorClientBuilder, come descritto nell'elenco seguente:

• Il metodo loadBalancingUpdateInterval(Duration) indica la frequenza con cui viene eseguito il ciclo di bilanciamento del carico.
• Il metodo partitionOwnershipExpirationInterval(Duration) indica la quantità minima di tempo trascorso dall'aggiornamento del record di proprietà, prima che il processore consideri una partizione non creata.

Ad esempio, se un record di proprietà è stato aggiornato alle 9:30 e partitionOwnershipExpirationInterval è di 2 minuti. Quando si verifica un ciclo di bilanciamento del carico e si nota che il record di proprietà non è stato aggiornato negli ultimi 2 minuti o entro le 9:32, considererà la partizione non creata.

Se si verifica un errore in uno dei consumer di partizione, chiuderà il consumer corrispondente, ma non tenterà di recuperarlo fino al successivo ciclo di bilanciamento del carico.

"... il ricevitore corrente '<RECEIVER_NAME>' con periodo '0' viene disconnesso"

L'intero messaggio di errore è simile all'output seguente:

New receiver 'nil' with higher epoch of '0' is created hence current receiver 'nil' with epoch '0'
is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used.
TrackingId:<GUID>, SystemTracker:<NAMESPACE>:eventhub:<EVENT_HUB_NAME>|<CONSUMER_GROUP>,
Timestamp:2022-01-01T12:00:00}"}

Questo errore è previsto quando si verifica il bilanciamento del carico dopo EventProcessorClient l'aggiunta o la rimozione delle istanze. Il bilanciamento del carico è un processo in corso. Quando si usa BlobCheckpointStore con il consumer, ogni ~30 secondi (per impostazione predefinita), il consumer verifica quali consumer hanno un'attestazione per ogni partizione, quindi esegue una logica per determinare se è necessario "rubare" una partizione da un altro consumer. Il meccanismo del servizio usato per asserire la proprietà esclusiva su una partizione è noto come Periodo.

Tuttavia, se non vengono aggiunte o rimosse istanze, esiste un problema sottostante che deve essere risolto. Per altre informazioni, vedere la sezione Modifiche frequenti alla proprietà della partizione e l'archiviazione di problemi di GitHub.

Utilizzo elevato della CPU

L'utilizzo elevato della CPU è in genere dovuto al fatto che un'istanza possiede troppe partizioni. È consigliabile non più di tre partizioni per ogni core CPU. È preferibile iniziare con 1,5 partizioni per ogni core CPU e quindi testare aumentando il numero di partizioni di proprietà.

Memoria insufficiente e scelta delle dimensioni dell'heap

Il problema di memoria insufficiente può verificarsi se l'heap massimo corrente per la JVM non è sufficiente per eseguire l'applicazione. È possibile misurare il requisito dell'heap dell'applicazione. Quindi, in base al risultato, ridimensionare l'heap impostando la memoria heap massima appropriata usando l'opzione -Xmx JVM.

Non è consigliabile specificare -Xmx come valore maggiore della memoria disponibile o del limite impostato per l'host (macchina virtuale o contenitore), ad esempio la memoria richiesta nella configurazione del contenitore. È necessario allocare memoria sufficiente per l'host per supportare l'heap Java.

I passaggi seguenti descrivono un modo tipico per misurare il valore per max Java Heap:

1. Eseguire l'applicazione in un ambiente vicino all'ambiente di produzione, in cui l'applicazione invia, riceve ed elabora eventi con il carico massimo previsto nell'ambiente di produzione.

2. Attendere che l'applicazione raggiunga uno stato stabile. In questa fase, l'applicazione e la JVM avrebbero caricato tutti gli oggetti di dominio, i tipi di classe, le istanze statiche, i pool di oggetti (TCP, pool di connessioni DB) e così via.

   Nello stato stabile viene visualizzato il motivo a forma di sawtooth stabile per l'insieme heap, come illustrato nello screenshot seguente:

   

3. Dopo che l'applicazione raggiunge lo stato stabile, forzare un'operazione di Garbage Collection completa usando strumenti come JConsole. Osservare la memoria occupata dopo il processo GC completo. Si vuole ridimensionare l'heap in modo che solo il 30% sia occupato dopo il GC completo. È possibile usare questo valore per impostare le dimensioni massime dell'heap (usando -Xmx).

Se si usa il contenitore, ridimensionare il contenitore in modo da avere circa 1 GB di memoria aggiuntivi per l'istanza non heap necessaria per l'istanza JVM.

Il client del processore smette di ricevere

Il client del processore viene spesso eseguito continuamente in un'applicazione host per giorni alla fine. In alcuni casi, si nota che EventProcessorClient non elabora una o più partizioni. In genere, non sono disponibili informazioni sufficienti per determinare il motivo per cui si è verificata l'eccezione. L'arresto EventProcessorClient è il sintomo di una causa sottostante (ovvero la race condition) che si è verificata durante il tentativo di ripristino da un errore temporaneo. Per le informazioni necessarie, vedere Archiviazione di problemi di GitHub.

EventData duplicato ricevuto al riavvio del processore

Il EventProcessorClient servizio Hub eventi e garantisce un recapito at-least-once . È possibile aggiungere metadati per distinguere gli eventi duplicati. Per altre informazioni, vedere Hub eventi di Azure garantisce un recapito almeno una volta? in Stack Overflow. Se è necessario il recapito una sola volta, è consigliabile prendere in considerazione bus di servizio, che attende un riconoscimento dal client. Per un confronto dei servizi di messaggistica, vedere Scelta tra i servizi di messaggistica di Azure.

Eseguire la migrazione dalla libreria legacy alla nuova libreria client

La guida alla migrazione include i passaggi per la migrazione dal client legacy e la migrazione di checkpoint legacy.

Passaggi successivi

Se le linee guida per la risoluzione dei problemi in questo articolo non consentono di risolvere i problemi quando si usano le librerie client di Azure SDK per Java, è consigliabile segnalare un problema nel repository GitHub di Azure SDK per Java.