Storm客户端提交任务失败原因分析

storm客户端提交topology失败:

java.lang.RuntimeException: org.apache.thrift7.transport.TTransportException
        at backtype.storm.StormSubmitter.submitTopology(StormSubmitter.java:141)
        at backtype.storm.StormSubmitter.submitTopologyWithProgressBar(StormSubmitter.java:176)
        at backtype.storm.StormSubmitter.submitTopologyWithProgressBar(StormSubmitter.java:158)
        at cn.com.tiza.dataquality.service.service.JobService.start(JobService.java:93)
        at cn.com.tiza.dataquality.service.service.JobService.submit(JobService.java:149)
        at cn.com.tiza.dataquality.service.resource.JobResource.execute(JobResource.java:33)
        at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)

nimbus.log:

2017-11-17T16:12:27.038+0800 b.s.d.nimbus [WARN] Topology submission exception. (topology name='dq23') #<IllegalArgumentException java.lang.IllegalArgumentException: storm-local/nimbus/inb
ox/stormjar-bc004b80-5f6e-4b94-9505-911511e5cc1f.jar to copy to storm-local/nimbus/stormdist/dq23-94-1510906347 does not exist!>
2017-11-17T16:12:27.038+0800 o.a.t.s.TNonblockingServer [ERROR] Unexpected exception while invoking!
java.lang.IllegalArgumentException: storm-local/nimbus/inbox/stormjar-bc004b80-5f6e-4b94-9505-911511e5cc1f.jar to copy to storm-local/nimbus/stormdist/dq23-94-1510906347 does not exist!
        at backtype.storm.daemon.nimbus$fn__4364.invoke(nimbus.clj:1173) ~[storm-core-0.9.7.jar:0.9.7]
        at clojure.lang.MultiFn.invoke(MultiFn.java:236) ~[clojure-1.5.1.jar:na]
        at backtype.storm.daemon.nimbus$setup_storm_code.invoke(nimbus.clj:307) ~[storm-core-0.9.7.jar:0.9.7]
        at backtype.storm.daemon.nimbus$fn__4261$exec_fn__1104__auto__$reify__4274.submitTopologyWithOpts(nimbus.clj:953) ~[storm-core-0.9.7.jar:0.9.7]
        at backtype.storm.daemon.nimbus$fn__4261$exec_fn__1104__auto__$reify__4274.submitTopology(nimbus.clj:966) ~[storm-core-0.9.7.jar:0.9.7]
        at backtype.storm.generated.Nimbus$Processor$submitTopology.getResult(Nimbus.java:1240) ~[storm-core-0.9.7.jar:0.9.7]
        at backtype.storm.generated.Nimbus$Processor$submitTopology.getResult(Nimbus.java:1228) ~[storm-core-0.9.7.jar:0.9.7]
        at org.apache.thrift7.ProcessFunction.process(ProcessFunction.java:32) ~[storm-core-0.9.7.jar:0.9.7]
        at org.apache.thrift7.TBaseProcessor.process(TBaseProcessor.java:34) ~[storm-core-0.9.7.jar:0.9.7]
        at org.apache.thrift7.server.TNonblockingServer$FrameBuffer.invoke(TNonblockingServer.java:632) ~[storm-core-0.9.7.jar:0.9.7]
        at org.apache.thrift7.server.THsHaServer$Invocation.run(THsHaServer.java:201) [storm-core-0.9.7.jar:0.9.7]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_144]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_144]
        at java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]

 

 

经过分析nimbus有个clean-inbox的机制来定时清理inbox中的jar文件,并有两个配置项来设置定时策略:

/**
 * How often nimbus should wake the cleanup thread to clean the inbox.
 * @see NIMBUS_INBOX_JAR_EXPIRATION_SECS
 */
public static final String NIMBUS_CLEANUP_INBOX_FREQ_SECS = "nimbus.cleanup.inbox.freq.secs";

/**
 * The length of time a jar file lives in the inbox before being deleted by the cleanup thread.
 *
 * Probably keep this value greater than or equal to NIMBUS_CLEANUP_INBOX_JAR_EXPIRATION_SECS.
 * Note that the time it takes to delete an inbox jar file is going to be somewhat more than
 * NIMBUS_CLEANUP_INBOX_JAR_EXPIRATION_SECS (depending on how often NIMBUS_CLEANUP_FREQ_SECS
 * is set to).
 * @see NIMBUS_CLEANUP_FREQ_SECS
 */
public static final String NIMBUS_INBOX_JAR_EXPIRATION_SECS = "nimbus.inbox.jar.expiration.secs";

NIMBUS_CLEANUP_INBOX_FREQ_SECS: 表示nimbus多久唤醒一次清理线程去进行清理;

NIMBUS_INBOX_JAR_EXPIRATION_SECS:表示jar文件在inbox中存活的时长,在清理线程清理之前如果到期了就会被清理

 

另一方面,通过storm-core提供的StormSubmitter.submitTopology的方法进行提交任务时,上传jar包的逻辑如下:

    private static String submittedJar = null;

    private static void submitJar(Map conf, ProgressListener listener) {
        if(submittedJar==null) {
            LOG.info("Jar not uploaded to master yet. Submitting jar...");
            String localJar = System.getProperty("storm.jar");
            submittedJar = submitJar(conf, localJar, listener);
        } else {
            LOG.info("Jar already uploaded to master. Not submitting jar.");
        }
    }

只要客户端进程不停,jar包就只上传一次。

 

所以等一个小时后,jar会被清除,重新提交任务就找不到inbox中的jar文件。

转载于:https://my.oschina.net/shipley/blog/1798992

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Flink、Storm、Spark是三种常见的大数据处理框架。下面我将针对这三种框架进行对比分析。 首先,Flink是一种流式处理引擎,可以提供低延迟和高吞吐量的流式数据处理。Flink提供了复杂事件处理、窗口操作和状态管理等功能,适用于需要实时处理和分析大规模数据的场景。相比之下,Storm是另一种流处理框架,它提供了类似的功能,但在低延迟方面表现更佳。Storm采用了可扩展的分布式架构,可以在分布式环境下处理海量的流式数据。Spark则是一种批处理和流处理框架的结合体,它不仅支持实时处理,还能处理离线批量数据。Spark提供了强大的查询和计算能力,适用于各种复杂的数据处理任务。 其次,Flink和Spark都支持内存计算,可以将数据存储在内存中进行快速计算,提高了处理效率。相比之下,Storm主要侧重于低延迟,因此在处理大规模数据时可能会受到性能瓶颈的限制。此外,Flink和Spark都提供了对常见数据源的支持,如Hadoop、Kafka等,可以方便地与其他系统集成。而Storm虽然也支持多种数据源,但通常需要自定义开发来实现集成。 最后,Flink和Spark都提供了比Storm更强大的容错机制。它们都可以通过将数据进行分区和复制来确保数据的安全性和可靠性。而Storm在容错方面相对较弱,需要用户自行实现。 综上所述,Flink适用于需要实时处理和分析大规模数据的场景,Spark适用于对大规模数据进行离线和实时处理的场景,而Storm则更适合对低延迟有强需求的场景。选择合适的框架应根据具体需求和场景来决定。 ### 回答2: flink、storm 和 spark 都是流式计算框架,但它们在设计理念、架构和应用场景上有所差异。 flink 的设计目标是提供一种高性能、高吞吐、低延迟和容错性强的流处理框架,可以进行流式和批处理计算。flink使用了基于事件驱动的分布式流处理模型,并提供了丰富的操作符和状态管理机制。flink还支持迭代计算和图计算,使其在迭代、图计算等复杂应用场景下具有优势。 storm 是一个开源的分布式实时计算框架,它提供了可靠性强、高性能的实时数据处理能力。storm使用了层次化的拓扑结构,能够处理实时和流式数据流,适用于需要低延迟、高吞吐的实时计算场景。storm具有较高的可伸缩性和容错性,但其执行模型相对简单。 spark 是一个通用的大数据处理框架,可以进行批处理、流处理和机器学习等各种计算任务。spark 提供了基于内存的计算引擎,具有更快的数据处理速度。spark适用于灵活的数据分析和复杂的数据处理,拥有丰富的API和优化机制。但因为spark不是专为流处理设计,所以在低延迟和流式计算方面的性能可能不如flink和storm。 综上所述,flink、storm 和 spark 在设计目标和应用场景上有所差异。flink适用于复杂的流处理、迭代和图计算,storm适用于实时和流式数据的低延迟处理,spark适用于灵活的数据分析和复杂的批处理。选择合适的框架应考虑具体的业务需求和计算场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值