2015-11-01 17 views
6

Abbiamo una topologia tempesta in cui abbiamo configurato un beccuccio e due bulloni. Spout interroga continuamente i dati dal DB e invia tupli a prima bullone per qualche elaborazione. Il primo bullone esegue un po 'di elaborazione e invia tuple al secondo bullone che chiama il servizio web di terzi e invia i dati. Quindi, cosa sta succedendo dopo un po 'di tempo, l'ultimo bullone non sta ricevendo nessuna tupla e se riavviamo la topologia funziona bene. Solo l'ultimo bullone è in difficoltà qui. L'altro beccuccio e il primo bullone stanno funzionando bene, e io non sto usando la struttura acking. Ho configurato un solo lavoratore in questo caso ».L'attività Apache Storm Bolt non riceve messaggi dopo un po 'di tempo

TopologyBuilder builder = new TopologyBuilder(); 
    builder.setSpout("messageListenrSpout", new MessageListenerSpout(), 1); 
    builder.setBolt("processorBolt", new ProcessorBolt(), 20).shuffleGrouping("messageListenrSpout"); 
    builder.setBolt("notifierBolt", new NotifierBolt(),40).shuffleGrouping("processorBolt"); 
    Config conf = new Config(); 
     conf.put(Config.TOPOLOGY_SLEEP_SPOUT_WAIT_STRATEGY_TIME_MS, 10000); 
     //conf.setMessageTimeoutSecs(600); 
     conf.setDebug(true); 
     StormSubmitter.submitTopology(TOPOLOGY, conf, builder.createTopology()); 

risposta

2

È probabile che si verifichino problemi con un arretrato di tuple che causa timeout. Prova ad aumentare il suggerimento sul parallelismo per il 2 ° bullone poiché sembra che il tempo di elaborazione di uno sia molto più lungo di quello del primo bullone (ecco perché ci sarebbe un backlog nel 2 ° bullone). Se stai eseguendo questa topologia sul cluster, guarda l'interfaccia utente di Storm per vedere le specifiche.

+0

Ciao Chris, non sto utilizzando framework Acking. Storming ancora timeout il messaggio ?? Se i messaggi scadono, dove possiamo controllare i registri. E ho dato il suggerimento del parallelismo a 30 dell'ultimo fulmine. –

1

Ragazzi quando stavo eseguendo il debug della mia topologia, ho scoperto che se diciamo che lo spout sta mandando un messaggio veloce, ma il bullone si sta elaborando lentamente. In questo caso, il messaggio verrà messo in coda LMAX Disruptor Queue. Quindi il task di spout attende che sia vuoto. Se si prende il dump del thread, i thread si troveranno nello stato TIMED_WAITING. Quindi, abbiamo bisogno di configurare la topologia in modo tale da mantenere l'afflusso e il deflusso.

Problemi correlati